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Abstract 

The Hindley-Milner (HM) type system allows programmers to 
write polymorphic functions and automatically infers the types at 
which those functions are used. In this type system, the inferred 
types are always unambiguous, and every expression has a principal 
type. However, type inference is sometimes unwieldy or impossible 
- especially in the presence of type system extensions such as type 
classes and non-injective type-level functions. In these scenarios, 
programmers cannot provide type arguments explicitly, as HM 
requires such types to be invisible. 

In this paper, we describe an extension to HM that allows for 
visible type application. Our extension is based on a novel type 
inference algorithm, yet a declarative presentation of the system 
can be specified via a simple extension to HM. We prove that our 
extended system is a conservative extension of HM and admits 
principal types. We then extend our approach to a higher-rank type 
system with bidirectional type-checking. We have implemented 
this system in the Glasgow Haskell Compiler and show how our 
approach scales in the presence of complex type system features. 

1. Introduction 

The Hindley-Milner (HM) type system fTl ll lllTTI achieves remark- 
able concision. While allowing a strong typing discipline, a pro- 
gram written in HM need not mention a single type. The brevity of 
HM comes at a cost, however: HM programs must not mention a 
single type. While this rule has long been relaxed by allowing visi- 
ble type annotations (and even requiring them for various type sys- 
tem extensions), it remains impossible for systems based on HM, 
such as OCaml and Haskell, to use visible type application when 
calling a polymorphic function^ 

This restriction makes sense in the HM type system, where 
visible type application is unnecessary, as all type instantiations 
can be determined via unification. Suppose the function id has type 
V a. a — > a. If we wished to visibly instantiate the type variable 

1 Syntax elements appearing in a programmer’s source code are often called 
explicit, in contrast to implicit terms, which are inferred by the compiler. 
However, the implicit/explicit distinction is sometimes used to indicate 
whether terms are computationally significant (2D. Our work to applies 
only to the inferred vs. programmer-specified distinction, so we use visible 
to refer to syntax elements appearing in source code. 
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Figure 1. The type systems studied in this paper 



a (in a version of HM extended with type annotations), we could 
write this expression 

(id :: Int —¥ Int) 

This annotation forces the type checker to unify the provided type 
Int — > Int with the type a — > a, concluding that type a should 
be instantiated with Int. However, this annotation is a roundabout 
way of providing information to the type checker. It would be much 
more direct if programmers could provide type arguments directly, 
writing the expression 

id @lnt 
instead. 

So why do we want visible type application? Considering a lan- 
guage like Haskell - as implemented by the Glasgow Haskell Com- 
piler (GHC) - which is based on HM but extends it significantly, 
we find two main benefits. 

Type instantiation cannot always be determined by unification. 
Some Haskell features, such as type classes 1281 and GHC’s type 
families Ell ED, do not allow the type checker to unambigu- 
ously determine type arguments from an annotation. The current 
workaround for this issue is the Proxy type which clutters imple- 
mentations and requires careful foresight by library designers. Vis- 
ible type application improves such code. (See Section[2]) 

It is sometimes painful to determine instantiations via type anno- 
tations. Even when type arguments can be determined from an 
annotation, this mechanism is still not always friendly to develop- 
ers. For example, the variable to instantiate could appear multiple 
times in the type, leading to a long annotation. Partial type signa- 
tures help 1291 . but they don’t completely solve the problem. Sec- 
tion[2]also contains an example of this issue. 

Although the idea seems straightforward, adding visible type 
applications to the HM type system requires care, as we describe in 
Section^] In particular, we observe that we can allow visible type 
application only at certain types: those with specified type quantifi- 
cation. These types are known to the programmer via type anno- 
tation. Such types may be instantiated visibly. Their instantiations 
may also be inferred as usual, should the programmer omit type 
applications. 
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This paper presents a systematic study of the integration of vis- 
ible type application within the HM typing discipline. In particular, 
we study this new feature in the context of four novel type systems, 
summarized in Figure [T] 

Section presents System HMV, a conservative extension of 
the declarative HM type system. HMV makes a distinction between 
specified and generalized type quantification and with support for 
visible type application. This extended system retains HM’s sim- 
plicity and compositionality, making programs with visible type 
applications easy to reason about. 

Section |5]develops System V, a novel syntax-directed type sys- 
tem with visible type application that faithfully implements the 
specification of the previous section. This type system directly cor- 
responds to a type inference algorithm, called V. We show that al- 
though Algorithm V works differently than Algorithm VV OD, it re- 
tains the ability to calculate principal types. The key insight is that 
we can delay the instantiation of polymorphic variables until nec- 
essary. We prove that System V is sound and complete with respect 
to HMV, and that Algorithm V is sound and complete with respect 
for System V. These results show the principal types property for 
HMV. 

Our goal with this work is to extend the Glasgow Haskell Com- 
piler with visible type application. Doing so requires consider- 
ing interactions with the many type system extensions featured in 
that context. Most interactions are orthogonal, but our work has 
led us to reconsider the treatment of higher-rank polymorphism in 
GHC |23| . As with visible types, that feature is based on reasoning 
about user-specified polymorphism. 

Therefore, Section [6] extends our ideas to a bidirectional sys- 
tem with higher-rank types and, for full expressiveness, scoped type 
variables. This section includes a syntax-directed set of rules, called 
System SB, that adapts the design principles of System V to GHC’s 
current algorithm for higher-rank polymorphism. The section also 
includes a novel, simple, declarative specification of this bidirec- 
tional type system, called System B. We prove that System SB is 
sound and complete with respect to System B. 

System SB forms the basis for our implementation in the Glas- 
gow Haskell Compiler]^ Section [7] describes this implementation 
and elaborates on interactions between our algorithm and other fea- 
tures of GHC. 

Finally, Section [8] discusses related work. Additionally, Ap- 
pendix [G] presents a variant of Systems B and SB designed for 
comparison with the higher-rank type system of Dunfield and Kr- 
ishnaswami 0- 

The Appendices of this paper contain extended examples and 
detailed proofs of the properties studied about each of the systems. 

However, before we discuss how to extend HM type systems 
with visible type application, we first elaborate on why we would 
like this feature in the first place. The next section briefly describes 
two situations in Haskell where visible type applications would 
benefit programmers. 

2. Examples of visible type application 

When a Haskell library author wishes to give a client the ability 
to control type variable instantiation, the current workaround is the 
standard library’s Proxy type. 

data Proxy a = Proxy 

However, as we shall see, programming with Proxy is noisy and 
painfully indirect. With built-in visible type application, these ex- 



2 Our implementation is available from https : //github . com/ 
goldf irere/ghc at the popl-2016 tag. 



amples are streamlined and easier to work with^jln these examples 
and throughout this paper, unadorned code blocks are accepted by 
GHC 7.10, blocks with a solid gray bar at the left are ill-typed, and 
blocks with a gray background are accepted only by our implemen- 
tation of visible type application. 

2.1 Resolving type class ambiguity 

Suppose a programmer wished to normalize the representation 
of expression text by running it through a parser and then 
pretty printer. The normalize function below maps the string 
"7 - 1 * 0 + 3 / 3" to "((7 - (1 * 0)) + (3 / 3))", 
resolving precedence and making the meaning clearQ 

normalize :: String — y String 

normalize x = show ((read :: String — y Expr) x) 

However, the designer of this function can’t make it polymor- 
phic in a straightforward way. Adding a polymorphic type signature 
results in an ambiguous type, which GHC rightly rejects. 

normalizePoly :: V a. (Show a, Read a) =y String —y String 
normalizePoly x = show ((read :: String — > a) x) 

Instead, the programmer must add a Proxy argument, which is 
never evaluated, to allow clients of this polymorphic function to 
specify the parser and pretty-printer to use 

normalizeProxy :: V a. (Show a, Read a) 

=> Proxy a —y String — ► String 
normalizeProxy _ x = show ((read :: String — y a) x) 

normalizeExpr :: String —y String 

normalizeExpr = normalizeProxy (Proxy :: Proxy Expr) 

With visible type application, we can write these two functions 
more directlyj^] 

normalize :: V a. (Show a, Read a) =4> String —y String 
normalize x = show (read @a x) 

normalizeExpr :: String —y String 
normalizeExpr = normalize @Expr 

Although the show/ read ambiguity is somewhat contrived in 
this case, proxies are indeed useful in more sophisticated APIs. For 
example, suppose a library design would like to allow users of the 
library to choose the representation of an internal data structure to 
best meet the needs of their application. If the type of that data 
structure is not included in the input and output types of the API, 
then a Proxy argument is a way to give this flexibility to clients]^] 

2.2 Dependently-typed programming 

Our next example is an excerpt of a longer example of dependently- 
typed programming in GHC. Space constraints prevent us from 

3 Visible type application has been a GHC feature request since 2011. See 
https : //ghc .haskell . org/trac/ghc/ticket/5296 

4 These examples use the following functions from the standard library 

show :: Show a => a — y String 
read :: Read a > String —y a 

as well as user-defined instances of the Show and Read classes for the type 
Expr. 

5 Our new extension TypeApplications implies the extension 
AllowAmbiguousTypes, which allows our updated normalize defi- 
nition to be accepted. 

6 See http : / /stackoverf low. com/questions/27044209/ 

haskell -why- use -proxy 
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fully explaining the code here: more details about this example are 
available in Appendix [A] This code is inspired by examples from 
McBride’s ICFP 2012 keynote fl5l . 

GHC supports dependently-typed programming through two 
main features: type-level computation and indexed types. For the 
former, type families EISED and data type promotion (301 allow 
programmers to write functions using datatypes, such as booleans 
and lists, at the type level. For the latter, generalized algebraic 
datatypes (GADTs) 1221 allow type arguments to be non-uniform. 
For example, the equality GADT, defined below, is inhabited by 
Refl only when its two arguments are equal. 

data a b where 

Refl :: a a 

We can use these features in the following function that asserts 
an equality fact about type-level computation: We can commute a 
type family If with list cons (:). Note that fact takes two Proxy 
arguments; the type variables t and f appear only in arguments to 
the If type family and thus cannot be solved via unification. 

type family If cond t f where 
If ' True t f = t 
If ’ False t f = f 

fact :: V t f s b. Sing b —y Proxy t — y Proxy f — y 
{{If btf)’: s) :~: {If b (t ’: s) {f ’: s)) 

This fact is needed in the code below, which comes from a 
simple compiler from a boolean expression language to a stack 
machine. We use this fact when compiling conditional expressions, 
as shown below. (Again, more details are in the appendix.) Not only 
do we need to provide proxies when calling fact, but we must also 
provide a (long) type annotation for its return type. Because the 
result of fact is used as the scrutinee of a GADT pattern-match, 
GHC cannot use unification to resolve the type variable s in this 
type. Instead, the only way to supply s is through this annotation. 

compile {SCond {seO :: Sing eO) 

{sel :: Sing el) {se2 :: Sing e2)) = 
case ( fact {sEval seO ) 

{Proxy :: Proxy { Eva I el)) 

{ Proxy :: Proxy { Eva I e2)) :: 

{{If ( Eval eO) { Eva I el) ( Eval e2 )) ’: s) 

{If ( Eval eO) {{Eval el) ’: s) {{Eval e2) ’: s ))) of 
Refl — y compile seO ++ 

IFPOP ( compile sel) {compile se2) ::: Nil 

This situation could be slightly improved by adding a Proxy for s 
to fact. However, s appears outside of If in the type of fact, so 
the programmer may not be aware of the issue when writing fact’s 
type. 

In the presence of visible type application, we avoid the proxies 
altogether 

fact :: V t f s b. Sing b —y 

{{If btf)’: s) {If b (t ’: s) {f ’: s)) 

and provide the type arguments directly, without annotation 

compile {SCond seO {sel :: Sing el) {se2 :: Sing e2)) = 
case fact @{Eval el) @{Eval e2) @s {sEval seO) of 
Refl — y compile seO ++ 

IFPOP {compile sel) {compile se2) ::: Nil 

Summary In these cases, although Proxy solves the problem, the 
mechanism clutters code and requires library authors to design their 
functions to take Proxy arguments. Furthermore, once a library 



Why specified poly types? 

It may seem possible to characterize how GHC quantities 
type variables, in an attempt to define some sort of “canon- 
ical quantification” as a part of the type inference process. 
We could then prefer one version of the principal type of 
an expression over another, allowing us to predictably visi- 
bly instantiate type variables. However, various type system 
features mean that such a characterization would be terribly 
complicated. In particular: 

Class constraints don’t have a fixed ordering in types, and 
it is possible that a type variable is mentioned only in a 
constraint. Which of the following is preferred? 

V r m w a. {MonadReader r m 

, MonadWriter w m) => a —y m a 

V w m r a. {MonadWriter w m 

, MonadReader r m) => a —y m a 

Equality constraints and GADTs can add new quantified 
variables. Should we prefer the type V a. a — y a or the 
equivalent type V a b. {a ~ b) =$■ a — y bl 

Type abbreviations mean that quantifying variables as they 
appear in order in the term can be ambiguous without also 
specifying how type abbreviations are used and when they 
are expanded. Suppose 

type Phantom a = Int 
type Swap a b = {b, a) 

Should we prefer dab. Swap a b — » Int or 

V b a. Swap a b — ^ Inti Similarly, should we prefer 

V a. Phantom a —y Int or Int — y Inti 

Type families also disturb variable ordering. Suppose 

type family Swap {a :: *) :: * 
type instance Swap {a, b) = {b, a) 

Should we prefer dab. Swap (a, b) — y Int or 

V b a. Swap (a, b) —y Inti This issue is harder to 
solve than the difficulty with vanilla type synonyms, as 
type families may or may not be able to reduce. 



author has specified that a function should take a Proxy argument, 
then it must always be called with a proxy. 

In contrast, visible type application requires little planning from 
library designers, can be used with less clutter, and need not be used 
at all in situations where unification can already determine the type 
argument. 

These examples are not the only ones that we have seen. Haskell 
programmers make frequent use of Proxy. Appendix[A]contains an 
additional longer example of the benefit of visible type application. 

3. Our approach to visible type application 

Visible type application seems like a straightforward extension, but 
adding this feature - both to GHC and to the HM type system that 
it is based on - turned out to be more difficult and interesting than 
we first anticipated. In particular, we encountered two significant 
problems when trying to extend the HM type system with visible 
type application. 

3.1 Just what are the type parameters? 



3 



2015/7/10 





The first problem is that it is not always clear what the type 
parameters to a polymorphic function are! 

One aspect of the HM type system is that it permits expressions 
to be assigned any number of isomorphic types. For example, the 
identity function for pairs 

pid (x,y) = (x,y) 

can be assigned any of the following types 

(1) V a b. (a, b ) — > (a, b ) 

(2) V a b. (b, a) — > (b, a) 

(3) Vcai. (a, b) — > (a, b) 

All of these types are principal; no type above is more general than 
any other. However, the type of the expression 

id @lnt @Bool 

is very different depending on which “equivalent” type is chosen 
for pid 

( Int , Bool) —t ( Int , Bool) — pid has type (1) 

(Bool, Int) — > (Bool, Int) — pid has type (2) 

V b. (Bool, b) — > (Bool, b) — pid has type (3) 

Of course, there are ad hoc mechanisms for resolving this am- 
biguity. We could try to designate one of the above types (1-3) as 
the real principal type for id, perhaps by disallowing the quantifi- 
cation of unused variables (ruling out type 3 above) or by enforcing 
an ordering on how variables are quantified (preferring type 1 over 
type 2 above). Our goal would be to make sure that each expres- 
sion has a unique principal type, with respect to its quantified type 
variables. However, in the context of the full Haskell language, this 
strategy fails. There are just too many ways that types that are not 
a-equivalent can be considered equivalent by HM. (See the box on 
the preceding page for a summary.) 

In the end, although it may be possible to resolve all of these 
ambiguities, we prefer not to. That approach leads to a system 
that is fragile (a new extension could break the requirement that 
principal types are unique up to a-equivalence), difficult to explain 
to programmers (who must be able to determine which type is 
principal) and difficult to reason about. 

Our solution: specified polytypes Therefore, our system is de- 
signed around the following principle: 

Only “specified” type parameters can be instantiated via 
explicit type applications. 

In other words, we allow visible type application to instantiate a 
polytype only when both of the following are true: 

1. The polytype is already fixed: constraint solving will give us no 
more information about the type. 

2. The programmer may reasonably know what the type is. 

In practice, these guidelines mean that visible type application 
is available only on types that are given by an annotation. These 
restrictions follow in a long line of work requiring more user 
annotations to support more advanced type system features GS 
I22I123 I. See Section[7]for discussion on how our implementation in 
GHC works with our design principle. 

3.2 What is the specification of the type system? 

We don't want to extend just the type inference algorithm that GHC 
uses. We would also like to extend its specification, which is rooted 
in HM. This way, we will have a concise description (and better 
understanding) of what programs type check, and a simple way to 
reason about the properties of the type system. 



Our first attempt to add type application to GHC was based on 
our understanding of Algorithm W, the standard algorithm for HM 
type inference. This algorithm instantiates polymorphic functions 
only at occurrences of variables. So, it seems that the only new form 
we need to allow is a visible type right after variable occurrences 

X @Tl ... @T n 

However, this extension is not very robust to code refactoring. 
For example, it is not closed under substitution. If type applica- 
tion is only allowed at variables, then we can’t substitute for this 
variable and expect the code to still type check. Therefore our al- 
gorithm should allow visible type applications at other expression 
forms. But where else makes sense? 

One place that seems sensible to allow a type instantiation is 
after a polymorphic type annotation (such an annotation certainly 
specifies the type of the expression) 

(Ax — > x :: V a b. (a, b) —t (a, b)) @lnt 

Likewise, if we refactor this term as below, we should also allow a 
visible instantiation after a lefl 

(let y = ((Ax — t x) :: V a b. (a, b) — > (a, b)) in y) @ Int 

However, how do we know that we have identified all sites 
where visible type applications should be allowed? Furthermore, 
we may have identified them all for core HM, but what happens 
when we go to the full language of GHC, which includes features 
that may expose new potential sites? 

One way to think about this issue in a principled way is to 
develop a compositional specification of the type system, which 
allows type application for any expression that can be assigned a 
polytype. Then, if we develop an algorithm that is complete with 
respect to this specification, we will know that we have allowed 
type applications in all of the appropriate places. 

Our solution: lazy instantiation for specified polytypes This rea- 
soning, inspired by thinking about how to extend the declarative 
specification of the HM type system, has lead us to develop a novel 
algorithm for type inference. This algorithm, which we call Algo- 
rithm V, is based on the following design principle: 

Delay instantiation of “specified" type parameters until 

absolutely necessary. 

Although Algorithm W instantiates all polytypes immediately, 
it need not do so. In fact, it is possible to develop a sound and 
complete alternative implementation of the HM type system that 
does not do this immediate instantiation. Instead, instantiation is 
done only on demand, such as when a polymorphic function is 
applied to arguments. 

In the next section, we give this algorithm a simple specifica- 
tion, presented as a small extension of HM’s existing declarative 
specification. We then make the details of our algorithm precise by 
giving a syntax-directed account of the type system, characterizing 
where lazy instantiations actually must occur during type checking. 

4. HM with visible type application 

To make our ideas precise, we next review the declarative specifi- 
cation of the HM type system 1711171 (which we call System HM), 
and then show how to extend this specification with visible type 
arguments. 

4.1 System HM 

The grammar of System HM is shown in Figure [2] The expression 
language comprises the Curry-style typed A-calculus with the ad- 

7 In fact, the Haskell 2010 Report (T4) defines type annotations by expand- 
ing to a let-declaration with a signature. 
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HM_Abs 



Figure 2. Grammar for System HM 
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T Ipim 6l C2 ■ 72 



HM_APP 



dition of numeric literals (of type Int) and let-expressions. Mono- 
types are standard, but we quantify over a possibly-empty set of 
type variables in type schemes. Here, we diverge from standard no- 
tation and write these type variables in braces to emphasize that 
they should be considered order-independent. We sometimes write 
r for the type scheme V{ }. r with an empty set of quantified vari- 
ables, and write V{a}.V{6}.r to mean V{a, b}.r. Here - and 
throughout this paper - we liberally use the Barendregt convention 
that bound variables are always distinct from free variables. 

The declarative typing rules for System HM appear in Figure[3] 
(This figure also includes rules for our extended system, called 
System HMV, described in Section |4~2j ) System HM is not syntax- 
directed - rules HM_Gen and HM_Sub can apply anywhere. 

So that we can better compare this system with others in the 
paper, we make two small changes to the standard HM rules. 
Neither of these changes are substantial; our version types the same 
programs as the original. First, we allow the type of a let expression 
to be a polytype a, instead of restricting it to be a monotype r. (We 
discuss this change further in Section [5~2] ) Second, we replace the 
usual instantiation rule with HM_Sub. This rule allows the type of 
any expression to be to converted to any less general type in one 
step (as determined by the subsumption relation g\ <h m a 2 ). Note 
that in rule HM_InstG the lists of variables a\ and 02 need not be 
the same length. 

4.2 System HMV: HM with visible types 

System HMV is an extension of System HM, adding visible type 
application. A key detail in its design is its separation of specified 
type variables from those arising from generalization, as initially 
explored in Section [TT| Types may be generalized at any time in 
HMV, quantifying over a variable free in a type but not free in 
the typing context. The type variable generalized in this manner is 
not specified, as the generalization takes place absent any direction 
from the programmer. By contrast, a type variable mentioned in a 
type annotation is specified, precisely because it is written in the 
program text. 

4.2.1 Grammar 

The grammar of System HMV appears in Figure [4] The type lan- 
guage is enhanced with a new intermediate form v that quantifies 
over an ordered list of type variables. This form sits between type 
schemes and monotypes; as contain vs, which then contain rsQ 
Thus the full form of a type scheme a is V{a}, b. r, including both 
a set of generalized variables {a} and a list of specified variables 
b. Note that order never matters for generalized variables (they are 
in a set) while order does certainly matter for specified variables 



8 The grammar for System HMV redefines several metavariables. These 
metavariables then have (slightly) different meanings in different sections 
of this paper, but disambiguation should be clear from context. In analysis 
relating systems with different grammars (for example, in Lemma[IJ, the 
more restrictive grammar takes precedence. 



HM Int 



r Ihm n : Int 

r Ihm . G\ r, X.ai lh m fi2 - 

T lh m let x = ei in e 2 : a 2 
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HM Let 



r thm e : V{a}. a 

r Ifim . ai ai ^hm a 2 
r Itim 6 . a2 



HM_Gen 



HM SUB 



ai < hm a 2 



n[r/ai] = t 2 a 2 ^ ftv(\/{ai}. n) 
V{ai}.Tl <hm V{a 2 }.T 2 



HM_InstG 



r Ifimv e : a Extra typing rules for System HMV 
r closed T lh mv e : Ma. v 



T lh mv e @r : v[t/o\ 

v closed v = Va. t T fh mv e : t 
F fh mv (e : v) : v 



HMV_TAPP 



HMV Annot 



ai < hmv a2 



Tl [t/6] = T2 



HMV_InstS 



Va, b. n <hmv Va. T 2 

Vi [r/ai] <hmv V 2 a 2 £ ftv(V{ai}.vi) 
V{ai}. v\ <hmv V{a 2 }. V 2 



HMV_InstG 



Figure 3. Typing rules for Systems HM and HMV 



The grammar for HMV extends that for System HM (Figure [2]t: 



e 


::= . . . | e @r \ (e : v) 


expressions 


T 


::= 


monotypes 


V 


::= Va. r 


specified polytypes 


a 


::= V{a}.u 


type schemes 


r 


::= • | F, x:a 


contexts 



Figure 4. Grammar for System HMV 
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V{a, 6}. a — > b < hmv V{a}. a — >■ a 
Va, b. a — > b <h m , Int — » Int 
Va, b. a b <h m , Va. a — >■ Int 
Va, 6. a — >■ b <h m , V{a, b}. a — » b 
Va, b. a — >■ b <h mv V{b}. Int — > b 

Va, b. a — »• b Vb. /nt — >■ b 

V{a}. a — ► a Va. a —t a 



Works the same as <h m for type schemes 

Can instantiate specified variables 

Can instantiate only a tail of the specified variables 

Variables can be regeneralized 

Because of the right-to-left nature of HMV_InstS, must regeneralize 

Known variables are instantiated from the right, never the left 
Specified quantification is more general than generalized quantification 



Figure 5. Examples of HMV subsumption relation 



(the list specifies their order). We say that v is the metavariable for 
specified polytypes, distinct from type schemes a. 

Expressions in HMV include two new forms: e @t instantiates 
a specified type variable with a monotype r, while (e : v) allows us 
to put a type annotation on an expression. These type annotations 
are specified polytypes v and must not contain any free type vari- 
ables. (We lift this restriction in Section |6T| ) We do not allow an- 
notation by type schemes a, with quantified generalized variables: 
if the user writes the type, all quantified variables are considered 
specified. 

4.2.2 Typing rules 

The type system of HMV includes all of the rules of HM plus 
the new rules and relation shown at the bottom of Figure [3] The 
HMV rules inherited from System HM are modified to recur back 
to System HMV relations: in effect, replace all hm subscripts 
with hmv subscripts. Note, in particular, rule HM_SUB; in System 
HMV, this rule refers to the o\ <h m » 02 relation, described below. 

The most important addition to this type system is 
HMV_TAPP, which enables visible type application when the type 
of the expression is quantified over a specified type variable. 

Type annotations, typed with HMV_ANNOT, allow expressions 
to be assigned a specified polytype v = Va. r. The rule checks 
to make sure v is closed and then types the expression e at type 
t. Of course, in the T lh mv e : r premise, the variables a still 
(perhaps) appear in r, but they are no longer quantified. We call 
such variables skolems and say that skolemizing v yields r. In 
effect, these variables form new type constants when type-checking 
e. When the expression e has type r, we know that e cannot make 
any assumptions about the skolems a and that we can assign e the 
type Va. r. This is, in effect, specified generalization. 

The relation cri <h mv 02 (Figure [3} implements subsumption 
for System HMV. The intuition is that, if cri <h mv 02, then an 
expression of type o\ can be used wherever one of type 02 is 
expected. For type schemes, the standard notion of cri being a more 
general type than 02 is sufficient. However for specified polytypes, 
we must be more cautious. 

Suppose an expression x @ti @r2 type checks, where x has 
type Va, b. vi. The subsumption rule means that we can arbitrarily 
change the type of x to some v, as long as v <h m « Va, b.v 
Therefore, v must be of the form Va, b. V2 so that x @n @T2 will 
continue to instantiate a with n and b with T2. Accordingly, we 
cannot, say, allow subsumption to reorder the specified variables. 

However, it is safe to allow some instantiation of specified 
variables as part of subsumption, as in ruleHMV_lNSTS. Examine 
this rule closely: it instantiates variables from the right. This odd- 
looking design choice is critical. Continuing the example above, v 
could also be of the form Va, 6, c. V3. In this case, the additional 
specified variable c causes no trouble - it need not be instantiated 
by a visible application. But we cannot allow instantiation left- 
to-right as that would allow the visible type arguments to skip 
instantiating a or b. 

Further examples illustrating <h mv appear in Figure[5] 



4.3 Properties of System HMV 

We wish System HMV to be a conservative extension of System 
HM. That is, any expression that is well-typed in HM should 
remain well-typed in HMV, and any expression not well-typed in 
HM (but written in the HM subset of HMV) should also not be 
well-typed in HMV. 

Lemma 1 (Conservative Extension for HMV). Suppose T and e 
are both expressible in HM; that is, they do not include any type 
instantiations, type annotations, scoped type variables, or specified 
poly types. Then, T e : a if and only ifT l^ mv e : a. 

This property follows directly from the definition of HMV as 
an extension of HM. Note, in particular, that no HM typing rule 
is changed in HMV and that the <h mv relation contains <h m ; 
furthermore, the new rules all require constructs not found in HM. 

We also wish to know that making generalized variables into 
specified variables does not disrupt types: 

Lemma 2 (Extra knowledge is harmless). IfT, a;:V{a}. r fh mv e : 
a, then T, a;:Va. r It;™ e : a. 

This property follows directly from a context generalization 
lemma, stated and proven in Appendix [B] which states that we can 
generalize types in the context without affecting typability. Note 
that Va. t <hmv V{a}. r. 

In practical terms, Lemma [2] means that if an expression con- 
tains let x = ei in e2, and the programmer figures out the type 
assigned to x (say, V{a}. r) and then includes that type in an an- 
notation (as lets = (ei : Va. r) in e2), that the expression’s type 
does not change. 

However, note that, by design, context generalization is not as 
flexible for specified polytypes as it is for type schemes. In other 
words, suppose the following expression type-checks. 

let x = ((Ax — > x) :: V a b. (a, b ) — > (a, b)) in ... 

The programmer cannot then replace the type annotation with the 
type V a. a — > a, because x may be used with visible type applica- 
tions. This behavior may be surprising, but it follows directly from 
the fact that V a. a -> a ^hm» V a b. (a, b) — » (a, b). 

Finally, we would also like to show that a system with visible 
types retains the principal types property, defined with respect to 
the enhanced subsumption relation cri <h mv 02- 

Theorem 3 (Principal types for HMV). For all terms e well -typed 
in a context T, there exists a type scheme o p such that T fh mv e : cr p 
and, for all a such that T l^ mv e : cr, cr p <hmv 0 . 

Before we can prove this, we first must show how to extend 
HM’s type inference algorithm (Algorithm VV ©) to include vis- 
ible type application. Once we do so, we can prove that this new 
algorithm always computes principal types. 

5. Syntax-directed versions of HM and HMV 

The type systems in the previous section declare when programs 
are well-formed, but they are fairly far removed from an algorithm. 
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T, x:ti k e \ T2 
T b; As. e : ri — > r 2 



rte:r Typing rules for System C 
s:V{a}. r G T 



rti : t[t/ a] 

F , x:ti k e : t 2 
F ^ As. e : n — > t 2 



C_Var 



C_Abs 



T b; e : t 



V Abs 



r Iv ei : ti ->■ t 2 T b; e 2 : n 
Fk e ie2 :t 2 



V_App 



r ^ ei : n —>■ T2 r t e 2 : Ti 



r ^ ei e 2 : r 2 



rbn:/nt 



C_lNT 



rf 



C_App 



T lf e ” e : a T, x:a t e 2 : r 2 
r t let s = ei in e 2 : r 2 

Generalization for System C 

a = ftv(r)\ftv{T) T^eir 
T If 6 " e : V{a}.r 



C Let 



C_Gen 



We use ftv(a) to mean the free type variables of a type scheme a. 
We lift this to work on contexts: ftv{xTa) = U ftv(ai). 

Figure 6. Syntax-directed version of the HM type system 



r b e : v 



T b n : Int 



V INT 



r If e : Va. r 
no other rule matches 

r k e : r[r/a] 



s:V{a}. v G T 



V_lNSTS 



V VAR 



r if s : v[t/ a] 

r lf eT1 ei : cj i r, x:ai If e 2 : v 2 
T If let s = ei in e 2 : v 2 

r closed r if e : Va. v 



V Let 



L If e @r : v[t / a] 



V TAPP 



In particular, the rules HM_Gen and HM_SUB can appear at any 
point in a typing derivation. 



v closed u = Va.r r f e : r 
T If (e : v) : v 



V_Annot 



5.1 System C 

We can explain the HM type system in a more algorithmic manner 
by using a syntax-directed specification, called System C, in Fig- 
ure [6] This version of the type system, derived from Clement et al. 
151 , clarifies exactly where generalization and instantiation occur 
during type checking. Notably, instantiation occurs only at the us- 
age of a variable, and generalization occurs only at a let-binding. 
These rules are syntax-directed because the conclusion of each rule 
in the main judgment F lj e : r is syntactically distinct. Thus, from 
the shape of an expression, we can determine the shape of its typing 
derivation. 

However, the judgment T f e : r is still not quite an algo- 
rithm: it makes non-deterministic guesses. For example, in the rule 
C_Abs, the type n is guessed; there is no indication in the expres- 
sion what the choice for tt should be. The advantage of studying 
a syntax-directed system such as System C is that doing so sepa- 
rates concerns: System C fixes the structure of the typing derivation 
(and of any implementation) while leaving monotype-guessing as 
a separate problem. Algorithm W guesses the monotypes via uni- 
fication, but a constraint-based approach EMT) would also work. 

5.2 System V: Syntax-directed visible types 

Just as System C is a syntax-directed version of HM, we can also 
define System V, a syntax-directed version of HMV (Figure [ 7 }. 
However, although we could define HMV by a small addition to 
HM (two new rules, plus subsumption), the difference between 
System C and System V is more significant. 

Like System C, System V uses multiple judgments to restrict 
where generalization and instantiation can occur. In particular, the 
system allows an expression to have a type scheme only as a result 
of generalization (using the judgment V If en e : a). Generalization 
is, once again, available only in let-expressions. 



Tte:r 

no other rule matches 

— — V_MONO 

e f e : r 




a = ftv(v) \ftv(Y) T If e : v 
r hf" e : V{a}. v 



V_Gen 



Figure 7. Typing rules for System V 



However, the main difference that enables visible type anno- 
tation is the separation of the main typing judgment into two: 
T bt e : t and T If e : v. The key idea is that, sometimes, we 
need to be lazy about instantiating specified type variables so that 
the programmer has a chance to add a visible instantiation. There- 
fore. the system splits the rules into a judgment b; that requires e to 
have a monotype, and those in If that can retain quantification in a 
specified polytype. 

The first set of rules in Figure [ 7 ] as before, infers a monotype 
for the expression. The premises of the rule V_Abs uses this 
judgment, for example, to require that the body of an abstraction 
have a monotype. All expressions can be assigned a monotype; if 
the first three rules do not apply, the last rule V_InstS infers a 
polytype instead, then instantiates it to yield a monotype. Because 
implicit instantiation happens all at once in this rule, we do not need 
to worry about instantiating specified variables out of order, as we 
did in System HMV. 
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The second set of rules (the fj judgment) allow e to be assigned 
a specified polytype. Note that the premise of rule V_TAPP uses 
this judgment. 

System V’s V_VAR rule is like System C’s C_VAR rule: both 
look up a variable in the environment and instantiate its generalized 
quantified variables. The difference is that C_Var’s types can 
contain only generalized variables; System V’s types can have 
specified variables after the generalized ones. Yet we instantiate 
only the generalized ones in the V_VAR rule, lazily preserving the 
specified ones. 

Rule V_Let is similar to C_Let. The only difference is that the 
result type is not restricted to be a monotype. By putting V_Let in 
the fj; judgment and returning a specified polytype, we allow the 
following judgment to hold: 

■ I? (let x = (A y. y : Vo. a — > a) in x ) @lnt : Int — > Int 

The expression above would be ill-typed in a system that restricted 
the result of a let-expression to be a monotype. It is for this reason 
that we altered System HM to include a polytype in its HM_Let 
rule, for consistency with HMV. 

Rule V_Annot is identical to rule HMV_ANNOT. It uses the 
k judgment in its premise to force instantiation of all quantified 
type variables before regeneralizing to the specified polytype v. In 
this way, the V_ANNOT rule is effectively able to reorder specified 
variables. Here, reordering is acceptable, precisely because it is 
user-directed. 

Finally, if an expression form cannot yield a specified polytype, 
rule V_MONO delegates to k to find a monotype for the expression. 

5.3 Relating System V to System HMV 

Systems HMV and V are equivalent; they type check the same 
expression. We prove this correspondence using the following two 
theorems. 



The grammar for B extends that for System HMV (Figure |4|: 



e ::= 


expressions 


r ::= ... 


monotypes 


p ::= t\v 1 ->■ p 2 


rho- types 


4 > ::= r | Vi — > V2 


phi-types 


v ::= ypi.ij) 


specified polytypes 


0 ■.■.= V{a}.w 


type schemes 


T ::= • | T, x:o \ T, a 


contexts 



Tht) 



Type well-formedness 
ftv(v) C T 



Ty Scoped 



rke- 



Thv 

Synthesis rules for System B 
x:o £ T 

B VAR 



r ^ r => d 



T, x:r ^ e => v 
T fg Xx. e => r — > 



B Abs 



T ^ ei => vi — > V2 r k e2 <= vi 



T k: ei e2 => V 2 



B APP 



r ^ n => Int 



B Int 



T fjj ei => 01 T, x:ai ^ e2 => cr 
T ^ let z = ei in e 2 => cr 



B_Let 



Theorem 4 (Soundness of V against HMV ). 

1. IfY \ y e : t, then T fh mv e : t. 

2. IfY £ e : v, then T fr; mv e : v. 

3. IfY fj e " e : cr, then Y fh mv e : cr. 

Theorem 5 (Completeness of V against HMV). If Y ^ mv e : cr, 
then there exists o' such that T \^ en e : o' where o' <hmv o. 

The proofs of these theorems appear in Appendix |C| 

Having established the equivalence of System V with System 
HMV, we can note that Lemma[2](“Extra knowledge is harmless”) 
carries over from HMV to V. This property is quite interesting in 
the context of System V. It says that a typing context where all 
type variables are specified admits all the same expressions as one 
where some type variables are generalized. In System V, however, 
specified and generalized variables are instantiated via different 
mechanisms, so this is a powerful theorem indeed. 

It is mechanical to go from the statement of System V in Fig- 
urc[7]to an algorithm. In Appendix[D] we define Algorithm V which 
implements System V, analogous to Algorithm W which imple- 
ments System C. We then prove that Algorithm V is sound and 
complete with respect to System V and that Algorithm V finds prin- 
cipal types. Linking the pieces together gives us the proof of the 
principal types property for System HMV (Theorem |3j. Further- 
more, Algorithm V is guaranteed to terminate, yielding this theo- 
rem 



T ^ e => o a v ars(Y) 
Y ^ e =>V{a}.o 

T ^ e => (71 (71 <b (72 

T ^ e => 02 

Y h r T fb e => Va. v 



B Gen 



B_Sub 



r ^ e @r => v[t/ a\ 

Tht) v = Va. f Y,H k e <= <j) 
Y ^ (e : v) => v 



B TAPP 



B_ANNOT 



Y k e <= v Checking rules for System B 
T, x:vi k e <= V 2 



Y t Xx. e <= Vi — > V 2 



B DABS 



r t ei => (7i r, x\oi k e 2 <= v 

Y ^ let x = ei in e 2 <= v 

T fb e <= v a £ vars(Y) 

T fb e <= Va. v 



B_DLet 



B_Skol 



Theorem 6. Type-checking System V is decidable. 

6. Higher-rank type systems 

We now extend the design of System HMV to include two ex- 
tensions of the Hindley-Milner type system: higher-rank polymor- 



r fb e => (71 (71 < dsk V 2 

Yke<=V2 



B_Infer 



Figure 8. Grammar and typing rules for System B 
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<Tl <b O' 2 



Higher-rank instantiation 



B_REFL 

T <b T 



V 3 <b Vl V2 <bV4 „ ^ 

B_FUN 

V\ —¥ V2 <b V3 — > V4 



<t>i[r/b\ < b (j >2 
Va, b. <f> i <b Va. <j> 2 



B_InstS 



vi[r/a\ < b v 2 b£ftv(V{a}.v i) 
V{a}. vi <b V{b}. V 2 



B_InstG 



01 <d*sk P2 



Subsumption, after deep skolemization 



DSK_REFL 



V 3 <dsk Vl V2 <dsk p4 
Vl -¥ V2 <j sk V 3 -¥ p4 



DSK_FUN 



Visible type application means that higher-rank arguments can 
also be explicitly instantiated. For example, we can instantiate 
lambda-bound identifiers 

let foo :: (V a. a a) -> ( Int — > Int , Bool) 
foo = Xf — » (f @ Int, f True) 

in foo id 

Higher-rank types also mean that visible instantiations can oc- 
cur after other arguments are passed to a function. For example, 
consider this alternative type for the pair function 

pair :: V a. a — > V b. b — > (a, b) 

pair = Ax y — > (x, y) 

If pair has this type, we can instantiate b after providing the first 
component for the pair, thus 

bar = pair 2 @Bool 

— bar inferred to have type Bool — > (Int, Bool) 

In the rest of this section, we provide the technical details of 
these language features and discuss their interactions. As above, we 
start with a declarative specification of the type system, and then 
discuss its implementation through an equivalent syntax-directed 
variant. The syntax-directed system studied here is the basis of our 
implementation in GHC. 



<71 <dsk V2 



Subsumption, with deep skolemization 



prenex(v2) = Vc.p2 
01 [v/a][v'/b\ < 3sk p 2 
V{a}, b. <jn <dsk V2 



DSK_Inst 



Define prenex(v) = Va. p as follows: 

prenex(Va. r) = Va. r 

prenex(Va. vi — > V 2 ) = Va, b. v\ — > P 2 
whereV6.p2 = prenex(v 2) 



Figure 9. Subsumption relations for System B 



phism and scoped type variables. The former allows function pa- 
rameters to be used at multiple types, whereas the latter brings type 
variables into scope to be used in type annotations. Incorporating 
these extensions shows the generality of our work. Although these 
extensions come with their own complexities, there are no unpleas- 
ant interactions in the introduction of visible type application. 

In fact, there is synergy between higher-rank polymorphism 
and visible type application. GHC supports higher-rank polymor- 
phism os no through the use of programmer annotations. As in 
visible type application, this type system feature is enabled only for 
polytypes that have been specified through some type annotation. 

For example, the following function does not type check in 
the vanilla Hindley-Milner type system, assuming id has type 
Va.i-)a. 

let foo = \f — » (f 3, f True) in foo id 

Yet, with the RankNTypes language extension and the following 
type annotation, GHC is happy to accept this code 

let foo :: (V a. a — >• a) —y (Int, Bool) 
foo = Xf — y (f 3, f True) 

in foo id 



6.1 System B: Declarative specification 

Figures [8] and [9] show the syntax and typing rules of System 
B, a declarative bidirectional type system, supporting predicative 
higher-rank polymorphism, visible type application, and scoped 
type variables. This declarative type system itself is a novel contri- 
bution of this work. Although it is based on the type system studied 
by Peyton Jones et al. ESI, that work uses only a syntax-directed 
system to describe bidirectional propagation of higher-rank types. 

System B is defined by two mutually recursive judgments, T 1^ 
e =F o and T e <= v, specifying when types are synthesized 
and checked, respectively. In the first judgment, the type a is an 
output of the system, whereas in the second, the type v must be 
provided along with F and e. This system propagates specified type 
information through the abstract syntax tree via its T ^ e <= v 
judgment. 

Although this system is bidirectional, we also claim that it is 
declarative. In particular, the use of generalization (B_Gen), sub- 
sumption (B_SUB), skolemization (B_SKOL), and mode switching 
(B_lNFER), can happen arbitrarily in a typing derivation. Under- 
standing what expressions are well-typed does not require knowing 
precisely when these operations take place. 

Basic features of System B System B shares the same expression 
language of Systems HMV and V, retaining visible type application 
and type annotations. However, types in System B may have non- 
prenex quantification. The body of a specified polytype v is now a 
phi-type rj>\ a type that has no top-level quantification but may have 
quantification to the left or to the right of arrows. Note also that 
these inner quantified types are us, not as. In other words, non- 
prenex quantification is only over specified variables, never gener- 
alized ones. As we will see, inner quantified types are introduced 
only by user annotation, and thus there is no way the system could 
produce an inner type scheme, even if the syntactic restriction were 
not in place. Typing contexts T may now contain type variables; 
this change is used to implement scoped type variables. The func- 
tion wars (r) calculates all type variables that occur in F, including 
both the declared scoped type variables and the free type variables 
in typing assumptions. 

Type synthesis The synthesis judgment is identical to the typing 
judgment for HMV if we ignore direction arrows. This is unsurpris- 
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-a V6. 
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-A \fb. 
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—> 


Int ) —t 


Bool 


<b 
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Va, b. 


a 


-> 


b 


/b 


Int 


—t Va. 


a 


— > 


a 


/ b 



Int — > Bool — > Bool 
Int -A V6. b -A b 
Va. a -A Bool — > Bool 
(Va. a — > a) — > Bool 

Int —> Vb. Bool —> b 

Va. Int -A a -A a 



Can instantiate non-top-level variables 

The levels are independent; not all variables must be instantiated 
The levels are independent; we can skip a top-level quantifier 
<b supports contravariant instantiation through higher-rank types 

Specified variables are instantiated from the right 
Cannot move quantifiers for specified variables 



Int -A Va, b. a — > b <dsk Int — > V6. Bool — > b 
Int — > Va. a — > a <dsk Va. Int — > a — > a 
( Int — > V6. b — > b) — > Int <dsk (Va, b. a — > b — > b) — y Int 
V{a}. a — > a <d S k Va. a — > a 



<dsk can instantiate specified variables in any order 

Specified quantification can move with <d s k 

Out-of-order instantiation works contravariantly through arrows 

<dsk ignores the distinction between specified and generalized variables 



Figure 10. Examples of B subsumption, with both relations 



ing, as the previous systems essentially all work only in synthesis 
mode; they derive a type given an expression. The novelty of a bidi- 
rectional system is its ability to propagate type information toward 
the leaves of an expression. 

The subsumption rule (B_SUB) in the synthesis judgment cor- 
responds to HMV_SUB from HMV. However, the novel subsump- 
tion relation <b used by this rule, shown at the top of Figure [9] is 
one of two subsumption relations that appear in the type system. 
This (j i <b 02 judgment extends the action of <h mv to higher- 
rank types: in particular, it allows subsumption for generalized type 
variables (which can be quantified only at the top level) and in- 
stantiation for specified type variables. We sometimes say that this 
judgment enables inner instantiation because instantiations are not 
restricted to top level. Figure[l0]provides examples of this relation. 

Type checking The checking rules allow the higher-rank type 
system to take advantage of specified polytypes. This happens in 
two different ways. 

Rule B_DAbs is the key rule of the checking judgment. When 
we have propagated a type v\ -A V2 for an expression \x. e, 
B_DAbs uses the type vi as s’s type when checking e. This is 
the only place where we can type a function with a higher-rank 
type. Note that the synthesis rule B_Abs uses a monotype for the 
type of a;|^] 

Rule B_lNFER uses the stronger of the two subsumption rela- 
tions <dsk, shown at the bottom of Figure [9] and with examples in 
Figure [TO] This rule appears at precisely the spot in the derivation 
where a specified type from synthesis mode meets the specified 
type from checking mode. This relation, called deep skolemization, 
we take directly from prior work mo. It subsumes <b (that is, 
o\ <b V 2 implies o\ <dsk V 2 ) and provides a full subsumption 
relationship for higher-rank types. 

For brevity, we don’t explain the details of this relation here, in- 
stead referring readers to Peyton Jones et al. (Section 4.6) HD for 
much deeper discussion. However, we note that there is a design 
choice to be made here; we could have also used Odersky-Liiufer’s 
slightly less expressive higher-rank subsumption relation l20l in- 
stead. We present the system with deep skolemization for back- 
wards compatibility with GHC. See Appendix [G] for a discussion 
of this alternative. 

Rule B_SKOL skolemizes one variable - that is, if we are 
propagating a type quantified over a (specified) variable a, we 
continue propagating without the quantification. Fike other steps 

9 Higher-rank systems can also include an “annotated abstraction" form, 
\x:v. e. This form allows higher-rank types to be synthesized for lambda 
expressions as well as checked. However, this form is straightforward to 
add but is not part of GHC, which uses patterns (beyond the scope of this 
paper) to bind variables in abstractions. Therefore we omit the annotated 
abstraction form from our formalism. 



that skolemize, this turns the quantified variable effectively into 
a type constant. This rule is necessary in order to remove any 
outer quantification before rule B_DAbs can apply. Note that when 
we talk about skolemization, we are considering reading the rule 
“bottom-to-top” - the order of the checking propagation. If we read 
the rule “top-to-bottom”, then this is a simple V-introduction, or 
generalization, rule. 

The remaining checking rule, B_DLet, simply propagates type 
information into the body of a let-expression. 

Scoped type variables Scoped type variables increase the expres- 
siveness of our system; they were necessary for both examples in 
Section [2] Therefore, System B relaxes the HMV restriction that 
type annotations and instantiations must be closed. Instead, type 
annotations are allowed to introduce type variables, which are then 
in scope inside the annotation. 

This behavior matches that of GHC ED. For example, the type 
annotation on const below introduces the type variables a and b 
that can then be used in the definition of const. 

const = (Ax y — > (x :: a) :: V a b. a — > b — ¥ a) 

System B only introduces type variables in B_ANNOT, and there 
only variables quantified at the top level. 

An alternative design would be to introduce scoped type vari- 
ables in B_Skol instead of B_ANNOT. (Note that the skolemized 
variables are not brought into scope in that rule). However, we de- 
liberately avoided this design because it leads to strange scoping 
behavior, as we describe in Appendix [G] 

6.2 System SB: Syntax-directed Bidirectional type checking 

System B is a declarative type system and not an algorithm. Fig- 
ure|TT]shows the higher rank analogue of System V, called System 
SB. As with other syntax-directed systems, the form of the rule 
conclusions resolve the order in which the rules must be applied. 
System C shows how to restrict generalization to happen only in 
let-bindings; this treatment is retained through all of the systems in 
this paper. System V shows how to restrict instantiation: instantiate 
generalized variables eagerly at variable usage sites, and instanti- 
ate specified variables lazily, on demand. System SB must now fix 
the new declarative rule that can apply anywhere: skolemization. 
System SB requires all skolemization to occur first when check- 
ing: SB_DeepSkol is the only rule in the T lf b e <= v judgment, 
and is also the entry point for the non-skolemizing T lj b e 4= p 
judgment^ 

The interaction between rule SB_DeepSkol and SB_Infer 
is subtle, due to the use of deep skolemization as our higher- 



10 Our choice to skolemize before SB_DLET is arbitrary, as SB_DLet 
does not interact with the propagated type. 
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r lib e => 0 Synthesis for 0-types 
r , X'.t 4 e => v 



T lj b \x. e 



SB_Abs 



r lit, n => Int 

r 4 e => Va. 0 

no other rule matches 

r lib e => 0[r/a] 

r 4 e =£■ w Synthesis for v-types 
®:V{a}. «er 



SB INT 



SB_InstS 



SB_Var 



r 4 x =► v[t/o\ 

r la, ei =£■ vi — l V 2 r 4 e2 4= Vi 

r 4 ei e 2 => V 2 

T If™ ei => ai F, x\ai 4 e2 => V2 

T 4 let s = ei in e2 => V2 

r h r r | b e Va. u 



SB APP 



SB Let 



rhw 



F 4 e @t => v[t/ a] 
v = Va. 0 r, a l| b e 



SB_TAPP 



r 4 (e : U) =F V 

T lj b e => 0 

no other rule matches 

r 4 c =a 0 



SB_Annot 



SB Phi 



r If" e =► <7 



Synthesis and generalization 



r If e => v a = ftv(v) \ vars( r) 
T f" e => V{a}.v 



SB Gen 



T fa. e 



Checking a p-type 

r, x:vi f e 4= p 2 



T fa b \x. e <= v\ — > p2 

T f" ei => cri T,x:oi lib e2 <= p2 
T li b let s = ei in e2 - 4 = p2 



SB_DAbs 



SB_DLet 



rank subsumption relation. Note that SB_DeepSkol does not 
directly match up with B_Skol. It doesn’t just skolemize the top- 
level quantified variables; it skolemizes all positively quantified 
variables. For example, if the algorithm is checking against type 
Va. a — > V6. b — > a, it will skolemize both a and b, pushing in 
the type a — > b — > a. In fact, the post-skolemization checking 
judgment F li b e 4= p, requires that the provided type be a p-type 
- one with no quantifiers to the right of arrows. 

Deep skolemization is necessary in SB_DeepSkol because 
SB_lNFER uses the r 4 e => v synthesis judgment in its premise, 
instead of the T f " e => a judgment. This decision to avoid 
generalization was forced by GHC, where generalization is intri- 
cately tied into its treatment of let-bindings and not supported for 
arbitrary expressions. Compare SB_lNFER with B_lNFER, whose 
premise synthesizes a c-type. This difference means that, in the 
syntax-directed system, we require more instantiations in the typ- 
ing derivation above the SB_lNFER rule. If the checked type were 
not deeply skolemized, certain inner-quantified variables would be 
unavailable for instantiation. For an illuminating example, see Fig- 
ure^] 

Properties of System B and SB System SB faithfully implements 
System B. 

Lemma 7 (Soundness of System SB). 

1. If r fa b e => 0 then T fa e =4- 0. 

2. If T 4 e =4> v then V fa e => v. 

3. IfT f " e => a then T fa e => a. 

4. IfT 4 e <= v then F fa e v. 

5. IfT fa b e -t= p then r fa e -t= p. 

Lemma 8 (Completeness of System SB). 

1. IfT lb e => a then T If" e => a' where a' < b <7. 

2. IfT lb e <= v then T 4 e <= v. 

Furthermore, we also show that System B is flexible with re- 
spect to the instantiation relation < b . As in System HMV, this re- 
sult implies that making generalized variables into specified vari- 
ables does not disrupt types. 

Lemma 9 (Context Generalization). Suppose T' < b T. 

1. IfT lb e => a then there exists o' < b cr such that F / fa e => a' . 

2. IfT lb e 4= v and v < b v' then T' fa e <= v'. 

Proofs of these properties appear in AppendixjF] 

7. Integrating visible type application with GHC 

System SB is the direct inspiration for the type-checking algorithm 
used in our version of GHC enhanced with visible type applica- 
tion. Below, we describe describe interactions between visible type 
application and other features of GHC. 



T 4 e =*• Ul Vl <dsk p2 

no other rule matches 

— SB_lNFER 

T ljb e <= p2 



r 4 e ■*= v 



Checking a n-type 



7.1 Case expressions 

Typing rules for case analysis and if-expressions require that all 
branches have the same type. But what sort of type should that be? 
For example, consider the following expression 

if condition then id else (Ax —t x ) 



prenex(v) = Ma.p 
a £ vars(T) T fa b e <= p 



SB_DeepSkol 



Figure 11. Syntax-directed bidirectional type system 



Here, id has a specified polytype of V a. a — > a, but the expression 
Ax — > x does not. To make this code type check, GHC must find a 
common type for both branches. 

One option would be to generalize the type of Ax — ^ x and 
then choose V a. a — » a as the common supertype of itself and 
V{a}. a — > a. However, that may not be possible in general, as 
there may not always be a common instance of both types. 
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Assume F = a::V{a}. Int — > a — > a. We wish to type-check the expression ( x:lnt — » Va. a ■ 
x:V{a}. Int — > a — > a £ F 



T 1^ x => V{a}. Int — > a 



B VAR 



V{a}. Int — k a — > a <dsk Int — k Va. a 



a). Here is a valid derivation in System B: 
- B_InstG 



F L x <= Int — > Ma. a 



B Infer 



T ^ (x : Int — k Va. a — k a) => Int — k Va. a 



B_ANNOT 



Here is a valid derivation in System SB: 
a;:V{a}. Int —t a 



a £ F 






/nt 



SB VAR 



Int 



a <Ik Int 



Int 



a <dsk Int 



r lit x <= Int 



DSK_REFL 

DSK_Inst 

SB_Infer 



Int — > Va. a 



SB_DeepSkol 



F lj b (x : Int — k Va. a — k a) => Int — k Va. a 



SB_Annot 
- SB_Gen 



r If™ (a; : Int — > Va. a —t a) => Int — > Va. a - 

Note the deep skolemization in this derivation. If we did only a shallow skolemization at the point we use SB_DeepSkol, then a would not 
be skolemized. Accordingly, it would be impossible to instantiate the type of x with a in the use of the SB_Var rule. 

Figure 12. An example of why deep skolemization in SB_DeepSkol is necessary 



Instead, following prior work HE we require that if and case 
expressions synthesize monotypes. Accordingly, the type checker 
instantiates the type id above before unification. 

Note that specified polytypes are still available for type check- 
ing because we know the type that each branch should have. For 
example, the following declaration is accepted 

check! f :: Bool — » (V a. a — > a) — » (Bool, Int) 
checklf b = if True 
thenAf — > ( f True, f 5) 
else A f -¥ ( f False, f 3) 

7.2 Imported functions 

The key requirement of specified polytypes is that type variables 
are fixed and known to programmers. But, when is this the case? 

In the design of our implementation, we considered the pos- 
sibility that all imported functions could meet this requirement. 
This would allow visible type application for any imported func- 
tion, whether or not it was originally supplied with a type annota- 
tion. This decision is justified: programmers can use tools (such 
as ghci’s : browse command) to discover the types. This deci- 
sion also places the least burden on programmers, as library au- 
thors need not think about visible type application when deciding 
whether to specify the types of their functions. 

However, this design is also fragile. By allowing all imported 
functions to be visibly instantiated, the ordering of type variable 
quantification is now part of the specification of the function. Per- 
haps worse, there is no guarantee that this ordering will stay the 
same from one version of the compiler to the next. 

Furthermore, it is also unnecessary. Haskell library authors al- 
ready do put type signatures on many of their exported functions. 
For functions exported without a type signature, clients may easily 
add their own type specifications by rebinding imported functions. 

We thus chose the conservative design. Only imported functions 
with type signatures are considered to have specified types PI 

7.3 Partial type signatures 

Partial type signatures are a recent addition to GHC, allowing 
users to leave wildcards in types, allowing GHC to infer those parts 



1 1 If the type signature does not include an explicit V listing the type vari- 
ables, we use the order as they appear in the user-supplied type signature. 



of a type. Wildcards can appear in visible type arguments, allowing 
users to skip types GHC can infer. For example, if f has type 
V a b. a — > b — > (a, b), then we can write f @_ @[/nf] True [] 
to let GHC infer that a should be Bool but to visibly instantiate b to 
be [Int]. The existing partial type signatures machinery simply fills 
in the wildcard by unification, as it does when wildcards appear in 
type signatures. 

7.4 Futher extensions to visible type application 

Our implementation also gives us the chance to explore two related 
extensions in future work. 

Visible type binding in patterns Consider the following GADT 

data G a where 

MkG ::V b. G ( Maybe b) 

When pattern-matching on a value of type G a to get the construc- 
tor MkG, we would want a mechanism to bind a type variable to b, 
the argument to Maybe. A visible type pattern makes this easy 

case g of 

MkG @b — > ... 

The type variable b may now be used as a scoped type variable in 
the body of the match. 

Visible kind application The following function is kind- 
polymorphic 1301 

pr :: V (a :: k\ — > /ca ) (b :: k i). Proxy (a b) — > Proxy a 
pr _ = Proxy 

Yet, even with our extension, we cannot instantiate the kind param- 
eters /ci and /(2 visibly; all kind variables are treated as generalized 
variables. We expect to address this deficiency in future work. 

8. Related work and Conclusions 

Implicit arguments in dependently-typed languages Languages 
such as Coq ia. Agda ED, Idris E and Twelf |24| are not based 
on the HM type system, so their designs differ from Systems HMV 
and B. However, they do support invisible arguments. In these 
languages, an invisible argument is not necessarily a type; it could 
be any argument that can be inferred by the type checker. 

Coq, Agda, and Idris require all quantification, including that 
for invisible arguments, to be specified by the user. These languages 
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do not support generalization, i.e., automatically determining that 
an expression should quantify over an invisible argument (in addi- 
tion to any visible ones). They differ in how they specify the visi- 
bility of arguments, yet all of them provide the ability to override 
an invisibility specification and provide such arguments visibly. 

Twelf, on the other hand, supports invisible arguments via gen- 
eralization and visible arguments via specification. Although it is 
easy to convert between the two versions, there is no way to visibly 
provide an invisible argument as proposed in this paper. Instead, 
the user must rely on type annotations to control instantiations. 

Predicative, higher-rank type systems As we have already indi- 
cated, System B is directly inspired by GHC’s design for higher- 
rank types E2D- However, in this work we have pushed the design 
further, clarifying the treatment of scoped type variables and pro- 
viding a declarative specification for the type system. 

Our work is also related to recent work on using a bidirectional 
type system for higher-rank polymorphism by Dunfield and Krish- 
naswami |9j. called DK below. There are a few differences between 
the DK system and System B. The most significant difference is 
that the DK system never generalizes. All polymorphic types in 
their system would be considered specified. As a result, their sys- 
tem cannot infer prenex polymorphism: a function must have a type 
annotation to be polymorphic. Furthermore, System B includes two 
forms of subsumption. The more flexible relation <dsk requires two 
specified polytypes so is only available at mode switches. DK also 
includes this relation, though a weaker version. However, System 
B also includes implicit subsumption <b , which does not have an 
analogue in the DK system. Instead, the DK system requires an 
“application judgment form” for instantiation. Finally, DK uses a 
different algorithm for type checking than the one proposed in this 
work; though like this paper, it defers instantiations of specified 
polymorphism. An extended comparison with the DK system ap- 
pears in Appendix [G] 

Conclusion This work extends the HM type system with visi- 
ble type application, while maintaining important properties of that 
system that make it useful for functional programmers. Our exten- 
sion is fully backwards compatible with previous versions of GHC. 
It retains the principal types property, leading to robustness during 
refactoring. At the same time, our new systems come with simple, 
compositional specifications. 

While we have incorporated visible type application with all 
existing features of GHC, we do not plan to stop there. In particular, 
we hope that our mix of specified polytypes and type schemes 
will become a basis for additional type system extensions, such as 
impredicative types, type-level lambdas, and dependent types. 
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A. Extended examples using visible types 

In this section we present two longer examples that benefit from 
the addition of visible type application. The second expands and 
explains the code presented in Section[2] 

A.l Deferring constraints to runtime 

Recent work 21 uses the following definition to enable mixing 
static and dynamic typing in order to implement information-flow 
control in Haskelll‘~l 

class Deferrable (c :: Constraint) where 
assume :: V a. Proxy c — > (c =4- a) — > a 

The parameter to the class Deferrable is a constraint kind - that 
is, the kind classifying constraints that appear to the left of =4-. For 
example. Show a is a Constraint. The idea behind Deferrable is 
that, if a constraint is deferred, the program calculates at runtime 
whether or not the constraint holds. 

Let’s consider deferring an equality constraint, written n ~ T 2 
in Haskell. Equality constraints are ordinary constraints; in partic- 
ular, they have kind Constraint and can thus be deferred. How- 
ever, if we have some type variable a and wish to check if a is, 
say, Bool at runtime, we need runtime type information. Haskell’s 
Typeable feature |il_2:| implements runtime type information. If we 
have a function 

woozle :: Typeable a = 4 > a — » a 

then runtime information identifying the type a is available at 
runtime, in the body of woozle. 

Putting this all together, it seems reasonable to defer an equality 
constraint between two types if we have runtime type information 
for both of them: 

instance ( Typeable a, Typeable b) 

= 4 - Deferrable (a ~ b) where ... 

However, to implement assume , we need one more definition. 

A.1.1 Propositional equality: 

Recent standard libraries shipped with GHC contain the following 
datatype: 

data a b where 

Ref ! :: a a 

This datatype implements propositional equality. If you have a 
value pf :: n T 2 , that is a proof that types n and T 2 are 
equal. Pattern matching on pf reveals this equality to GHC’s type- 
checker, which can then use it in a pattern match: 

boolCast :: ( a Bool) — > a — ¥ Bool 

boolCast pf b = case pf of Refl —r b 

A. 1.2 Runtime cast 

The Typeable feature uses in an important function: 

eqT :: (Typeable a, Typeable b) =4- Maybe (a :~: b) 

Given runtime type information for a and b. this function condi- 
tionally provides a proof that a and b are equal. The eqT function, 
in turn, can be used to implement a runtime cast. 

We are now ready to assemble the pieces: 

instance ( Typeable a, Typeable b) 

=4- Deferrable (a ~ b) where 



12 Much of this example - including its use of deferring equality constraints 
- appears in Buiras et al. (2]|. However, our use of visible type application 
in this example is our own contribution, novel in this paper. 
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assume _ x = case eqT :: Maybe (a b) of 
Just Ref I — > x 

Nothing —>■ error "type error!" 

A. 1.3 Making assumptions 

Suppose we are working a list type that tracks whether it has surely 
one element, or whether there is an unknown length^Here are the 
relevant definitions: 

data Flag = Branched — 0 or more elements 
| Unbranched — exactly 1 element 

data List a ( b :: Flag ) = ... 
the :: List a Unbranched — > a 
the = ... 

In some places, it is hard to arrange for the type system to ascertain 
that a list is Unbranched, and calling the is impossible. However, 
with Deferrable, we can get around that pesky static type system: 

unsafeThe :: V a b. Typeable b => List a b — >■ a 
unsafeThe £ 

= assume ( Proxy :: Proxy (b ~ Unbranched)) 

( the £) 

The call to assume means that the £ is type-checked in an environ- 
ment where the constraint b ~ Unbranched is assumed. The call 
the £ then type-checks without a problem. 

A. 1.4 Deferring errors with visible type application 

This last snippet of code assumes a constraint, and the only way of 
specifying the constraint is via a Proxy. This is what visible type 
application can ameliorate. Let’s rewrite this example with visible 
type application. 

class Deferrable (c :: Constraint) where 
assume :: V a. (c =y a) — »• a 

instance ( Typeable a, Typeable b) 

=> Deferrable (a ~ b) where 
assume x = case eqT @a @b of 
Just Ref I — > x 

Nothing —>■ error "type error!" 
unsafeThe :: V a b. Typeable b => List a b — > a 
unsafeThe £ = assume @(b ~ Unbranched) ( the £) 

We have used visible type applications in two places here. One 
is to fix the type of the call to eqT. Because we immediately 
pattern-match on this result, GHC has no way of inferring the types 
at which to use eqT. In the previous version of this example, it was 
necessary to write eqT :: Maybe (a :~: b) here. This annotation 
is noisy, because we care only about the a and the b - the Maybe 
and :~: bits are fixed and add no information. It is easy to imagine 
more complex cases where the noise far outstrips the signal. 

The second use of visible type application is in the definition 
and call of assume, where no Proxy argument is now necessary. 
Once again, this has cleaned up our code and drastically reduced 
noise. 

Dependently-typed programming with Proxy Dependently- 
typed programming in GHC can require more extensive use of 
proxies. For example, based on Conor McBride’s ICFP 2012 
keynote OH, consider a stack-based compiler for a language of 

13 This example is from real code - just such a list is used within GHC when 
keeping track of type family axioms from either open mm or closed ED 
type families. 



boolean expressions. (The entire code for this example is available 
in the supplementary material.) 

data Expr :: *where 
Val :: Bool — > Expr 
Cond :: Expr — > Expr — > Expr — / Expr 
eval :: Expr — > Bool 
eval ( Val n) = n 

eval ( Cond eO el e2) = 
if eval eO then eval el else eval e2 

Using standard techniques, we can create a singleton type for 
expressions SExpr and a type-level function Eval that allow the 
type system to talk about these definitions. 

eval :: Expr — > Bool 
eval ( Val n) = n 

eval ( Cond eO el e2) = if eval eO then eval el else eval e2 
type family Eval (x :: Expr) :: Bool where 
Eval (’Val n) = n Eval (’ 

Cond eO el e2) = If ( Eval eO) ( Eval el) ( Eval e2) 

For example, the evaluator for singleton booleans states that it 
actually calculates the boolean denoted by the expression: 

sEval :: SExpr e — > SBool ( Eval e) 
sEval ( SVal n) = n 

sEval ( SCond eO el e2) = slf ( sEval eO) ( sEval el) ( sEval e2) 

However, instead of evaluating booleans directly, we would like 
to compile them to a list of instructions for a stack machine. At 
the same time, we would like to know that the resulting list of 
instruction will produce the correct answer when run. 

In other words, given a GADT representing instruction lists, that 
when run will take a stack from its initial configuration to the final 
configuration: 

data Inst ( initial :: [Bool]) ( final :: [Bool]) where 
— Add a value to the top of the stack 
PUSH :: Sing v — > Inst s ( v ’: s) 

— Compare the top value on the stack and branch 
IFPOP :: Listlnst s st —t Listlnst s sf 
Inst ( b ’: s) (If b st sf) 

— a list of instructions, also tracking the machine configurations 
data Listlnst ( initial :: [Bool]) ( final :: [Bool]) where 

Nil :: Listlnst i i 

(:::) :: Inst i j — t Listlnst j k — > Listlnst i k 

infixr 5 ::: 

— concatenate two lists, composing their stacks 
(++) :: Listlnst i j —y Listlnst j k — > Listlnst i k 
Nil ++ys = ys 

(x ::: xs) ++ys = x ::: (xs++ys) 

infixr 5++ 

We would like to define a compilation function that will create 
a list of instructions that, when run, will put the evaluation of an 
expression at the top of the stack. 

compile :: V (e :: Expr) (s :: [Bool]). 

SExpr e — > Listlnst s ((Eval e) ': s) 

The implementation of the compilation function is straightfor- 
ward in the case of a singleton boolean value. It just pushes that 
value on the top of an empty stack. 

compile (SVal y) = PUSH y ::: Nil 
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However, the compilation of conditionals runs into difficulties, 
we would like to use this code, which first compiles the scrutinee, 
and then appends the branch instruction. 

compile ( SCond seO sel se2 ) = 
compile seO ++ 

IFPOP ( compile sel) ( compile se2) ::: Nil 



and supply the type arguments visibly: 

compile ( SCond seO ( sel :: Sing el) ( se2 :: Sing e2 )) = 
case fact @(Eval el) @(Eval e2) @s ( sEval seO) of 
Refl — > compile seO ++ 

IFPOP ( compile sel) ( compile se2) ::: Nil 



However, for this code to type check, the compiler needs to 
know the following conversion fact about if expressions 

(If ( Eval eO) ( Eval el) ( Eval e2)) ’: vs) 

(If (Eval eO) ((Eval el) ’: vs) ((Eval e2) ’: vs)) 

We can “prove” this fact to the compiler, with a helper lemma, 
called fact below. Note, however that in the result of the lemma, the 
type variables t and f only appear as arguments to the type-level 
function If. Therefore, unification cannot be used to instantiate 
these arguments, so the Proxy type is necessary. 

fact :: V t f s b. Sing b —y Proxy t — > Proxy f —/ Proxy s 
H- ((If btf)’: s) :~: (If b (t ’: s) (f ’: s)) 

fact STrue = Refl 

fact SFalse = Refl 

We can call fact in the case for compile, by providing the 
appropriate Proxy arguments. 

compile (SCond seO (sel :: Sing el) (se2 :: Sing e2)) = 
case fact (sEval seO) (Proxy :: Proxy (Eval el)) 

(Proxy :: Proxy ( Eval e2)) (Proxy :: Proxy s) of 
Refl — > compile seO ++ 

IFPOP (compile sel) (compile se2) ::: Nil 

Note, that in our definition of fact above, we have made the 
argument s be specified via Proxy, even though it doesn’t techni- 
cally need to to be because it appears outside of the If in the type. 
GHC will also accept this alternative fact ’ that does not include a 
Proxy s argument. 

fact ’ :: V t f s b. Sing b — > Proxy t — > Proxy f 
-A ((If btf)’-. s) (If b (t ’: s) (f ’: s)) 

fact 'STrue = Refl 

fact ’ SFalse = Refl 

However, that version of fact is even more difficult to use. Be- 
cause the result of fact ’ is used as the argument of GADT pattern 
matching, GHC cannot use unification to resolve type variables in 
this type. Instead, to make this code type check, we require an even 
more extensive type annotation: 

compile (SCond (seO :: Sing eO) 

(sel :: Sing el) (se2 :: Sing e2)) = 
case (fact ’(sEval seO) 

(Proxy :: Proxy (Eval el)) 

(Proxy :: Proxy (Eval e2)) :: 

((If (Eval eO) (Eval el) ( Eval e2)) ’: s) :~: 

(If (Eval eO) ((Eval el) ’: s) ((Eval e2) ’: s ))) of 
Refl — > compile seO ++ 

IFPOP (compile sel) (compile se2) ::: Nil 

In the presence of visible type application, we would like to 
avoid the proxies all together: 

fact :: V t f s b. Sing b — > 

((If btf)’: s) :~: (If b (t ’: s) (f ’: s)) 
fact STrue = Refl 
fact SFalse = Refl 



B. Properties of System HMV 

Lemma 10 (Inversion for <hmv )• <Ji <h m » 02 if and only 
if oi = V{ai}, 62, 61. ti and <73 = V{a2}, 62- 72 where 

Ti[ri/ai][ri/ 6 i] = 72. 

Proof. By unfolding definitions. ED 

Lemma 11 (Reflexivity for <h mv )• Forall 0, o <h mv rr 
Proof. By definition. □ 

Lemma 12 (Transitivity for < hmv ). If 01 <h m » 02 an d 02 <hmv 
rr 3, then ^hmv o"3- 

Proof. Let 03 = V{ <13 1,63.73. Then, by inversion, we know 
o 2 = V{a 2 }, 63, 62-72 and r2[r 2 /a2][72/62] = 73. We further 
know < 7 i = V{ai},^ 3 , 62, 61. 7 i and 7 i[ 7 i/ai][ 7 i/ 6 i] = 7 2 . 
Thus, 71 [7! / ai] [Ti / 6 1 ] [72 / a 2 ] [72 / 62] = 73. By the Baren- 

dregt convention, we know that H2 do not appear in 71. Thus 
we can rewrite as 7i[7i[72/a]/ai][7 , i[7 2 /a2]/6i][72/6 2 ] = 73. 
This is enough to finish the derivation via HMV_InstS and 
HMV_InstG. n 

Lemma 13 (Substitution in <h m » ). 

1. Ifv 1 <hmv V2, thenvi[r/a\ < hm „ 7 i 2 [ 7 /a]. 

2 . If cri <hmv 02 , then 0-1(7/01] <h mv 02(7/01]. 

Proof. Immediate. □ 

Lemma 14 (Context Generalization for HMV). IfT fh mv e : o and 
r' <hmv r, then T' fhrrw e : o. 

Proof. This is by straightforward induction, with an appeal to 
HMV_SUB in the variable case (HMV_Var). ID 

Proof of Lemma^(E.xtra knowledge). This is a corollary of con- 
texts generalization as V{ 7 z} . 7 <h m , Va. 7. ID 

C. Proofs about System V 

Proof of Soundness of V against HMV (Theorem^. By induction 
on the appropriate derivation. Most cases follow directly via in- 
duction. 

Case V_lNSTS This case follows via induction and HMV_SUB 
using the fact that Va. 7 <h mv 7 [ 7 /a] by HMV_InstS. 

Case V_VAR This case follows via HMV_Var and HMV_Sub 
using the fact that Via - }. 7 <h m , 7(7/0] by HMV_InstG. 

□ 

Lemma IS (Context generalization for V). 

1. If T ^ e : v and r ; <h m » T, then there exists v’ such that 
V e : v‘ and v' <hmv v. 

2. IfT V e : 7 and T 7 <h m » T, then T 1 1 ; e : 7 

3. If T \^ en e : o and T' <h m « T, then there exists o' such that 
r / \^ en e : o' and o' <h m v o. 
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In all cases, the size of resulting derivation is no larger than the a is free in neither v nor T: In this case the substitution has no 
size of the input derivation. effect and we are done. 



Proof. By induction on derivations. Most cases are straightforward; 
we present the most illuminating cases below: 



Case V_Var: 

a;:V{a}. v £ T 

1 V_VAR 

r hj x : v [r/fflj 

Given :r:V{a , }.i/ £ F' where V{a , }.t/ <hmv V{a}.u, we 
must choose t' such that v'\t' /~ a'] <hmv v[r/a], Inverting 
<hmv gives us that v'[r'/d'] <hmv v. We are thus done by 
Lemma[l3l Note that the size of both derivations is 1. 

Case V_TApp: 



t closed 



rF e :Va.w 



re 



vt : v\r 



/a] 



V TAPP 



The induction hypothesis gives us T' e : v 1 where v' <h m » 
Va. v. By the definition of <h mv , v' must also be quantified 
over a. We can thus reduce to \/a.v" <hmv Va.v, which 
reduces to v" <hmv v. We must prove that v"\r/a\ <hmv 



v[t / a], which follows directly from v" <hrr 
and so we are done. 

Case V_Gen: 



v via Lemma 



13 



a = ftv(v) \ftv(T) r £ e : v 
r e : V{a}.v 



V_Gen 



The induction hypothesis gives us T' e : v 1 where v 1 <hmv 
v. By inversion, we know that v' = Va 1 , b . n and v = Va' . t 2 
where ri[r'/6 ] = T2. 

Let a = ftv(v)\ftv(T) and b = ftv(v')\ftv(T'). We want to 
show that V{6}. v' <hmv V{a}. v. Expanding out, we want to 
show that V{ b } , a\ b . n <hmv V{a}, a'. T2, where tl \f/b\ = 
T2 - Unfolding <hmv shows that we want ti \f / b] [r'/H = t 2 . 
Choose t = b and we are done. 



□ 



Lemma 16 (Substitution for V). 

1 . IfT ^ e : t', then r[r/o] k e : r'[r/o]. 

2. IfT Ij e : v, then r[r/o] ^ e : v[r/a]. 

3 . IfT \^ e71 e : cr, then r[r/a] e : a[r/a\. 

Proof. By induction, frequently using the Barendregt convention to 
rename bound variables to avoid coinciding with free variables. 

The interesting case is generalization: The premise of this case 
is F hj e : v where a = V{6}. v for b = ftv(v ) \ ftv(T). By the 
Barendregt convention, note that b do not contain a. 

The induction hypothesis gives us r[r/a] ly e : v[t / a]. Let 
c = ftv{v[r / a\) \ ftv(V[T / a]). To use V_Gen to conclude 
T \^ en e : (V{c}. w)[r/a], we must show that b = c and that 
c are not free in r. 

We now have several cases: 

a is free in both v and in T: In this case ftv(v[r/ a]) includes the 
free type variables of v, minus a, plus the free variables of r. 
Likewise, ftv(T[r/ a]) includes ftv(T), minus a, plus the free 
variables of r. In each case, the sets that produce c are changed 
by the same variables. Therefore, b and c must be equal. 
a is free in v but not free in I : To be in this case a must be in b, 
which cannot happen. 

a is not free in v but is free in F: In this case h = c and we are 
easily done. 



□ 



Proof of Completeness (Theorem^. We proceed by induction on 

r Ifimv e . (7. 



Case HMV_YAR: Straightforward, using the types a to instanti- 
ate the variables a in V_VAR. We know these a are not free 
in T by the Barendregt convention. It may be the case that 
generalization quantifies over more variables, i.e. a C o' = 
ftv(v) \ ftv(T), leading to a more general result type. How- 
ever, that is permitted by the statement of the theorem. 

Case HMV.Abs: 



r, X.T\ fhrrw 6 • T2 

r \x. e : Tl — > T2 



HMV_Abs 



The induction hypothesis gives us T, x\t\ e : V{a}, b. T2 
where T2 = xffj’ /b\\fr /~a\. Inverting Ij 6 ’ 1 gives us T, x\t\ ij 
e : V6.T2. We can then use V_InstS and V_Abs to get 
r T; Xx. e : ti — > T2,\t' / b\. Generalizing, we get F \^ en 
Xx.e : V{a, a'j.ri — » r'ffr' fb\ where the new variables 
a' come from generalizing n and the r . We can see that 
(ri — >■ T2[r'/6])[r/ffl] = ri — > T2 and so V{a, a'}, n — > 
Tnffr' / b] <hmv ti — > T2 and we are done. 

Case HMV_App: 



r Iprnv . Tl ^ T2 T llimv ^2 ■ Tl 

r Ipmv ^1 e2 ■ T2 



HMV_App 



The induction hypothesis gives us T \^ en ei : 
V{ai}, fti.Tn -s- T12 withTi = T11 [ri/ai] [ t'i / 61] and t 2 = 
Ti2[Ti/ai][Ti/6i], along with T e2 : V{a2}, 62.T21 with 
Ti_ = T2i[T2/a2][T2/6 2 ]. Inverting \^ en gives us F ^ ei : 
V61. Tn -> T12 and T ^ e2 : Vf>2. T21. 



We now use the Substitution Lemma (Lemma with the 
substitution [Ti/ai] on the first of these to yield T Ij; ei : 
V&i. Tn [ ti/ui] — > T12 [t 1 /"fz 1 ] . Note that the Hi must not be 
free in T, by inversion of \^ en . Similarly, Lemma 16 gives us 

F ^ e 2 : V&2-T 2 i[T2/a2]. 



We can then use V_InstS on both of these judgments, to 
show r k ei : Tn[Ti/ai][Ti/6i] -A Ti 2 [Ti/ai][T'i/fei] and 
F e 2 : T 21 [T 2 /H 2 ] [T 2 / 62 ], 

We can now now use V_APP, as the argument type is equal to 
Ti, established earlier. Rule V_APP then gives us T ^ ei e 2 : 
ti2[ti/oi][ti/&i]. This type, as noted earlier, equals T2, and 
so we are done. 

Case HMV_Int 



F fhmv n : Int 



Trivial. 

Case HMV_TApp: 



HMV_Int 



t closed T e : Va. v 
r bimv e @t : v[T/a\ 



HMV_TAPP 



The induction hypothesis (after inverting \^ en ) gives us T hjj e : 
Va.v 1 , where b = ftv(Va.v') \ ftv(T) and v'[T/b] <hmv 
v. Applying V_TAPP gives us T ij e @t : v'[t/o\, 

and V_Gen gives us T l^ en e @t : V{c}. v'[t/o\ 

where c = ftv{v'[T / a\) \ ftv(T). We want to show that 
V{c}. v'[t/ a] <hmv v[t/ a], which follows when there is some 
t', such that v'[t / o][t' /c] <hmv v[t/ a] . 

This is equivalent to exchanging the substitution, i.e. finding a 
t' such that v'[t' / c] [t / a] <h m » v[t/ a]. 
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By Substitution (Lemma |l3f, we have w'[r/ 6 ][r/a] <h m » 
v[t / a]. We also know that the b are a subset of the c. So we 
can choose t' to be r for the b, and the remaining c elsewhere, 
and we are done. 

Case HMV_Let: 



r ipimv Ol . (71 L, X.(J\ i^imv 02 ■ <72 

r fh mv let x = ei in e 2 : cr 2 



HMV Let 



The induction hypothesis gives us T \^ en ei : a'i with <hmv 
or. The induction hypothesis al so g ives us T, x:oi \^ en e 2 : <72 
with <72 <hmv (72. Use Lemma [15] to get T, x:a[ [f en e 2 : a '2 
where a'i < h „ a' 2 . 

Let <72 = V{6}.t> where b = ftv(v) \ ftv(T). Inverting 
If ' en gives us T, x:a[ e 2 : v. We then use V_Let to get 
T ij let x = ei in e 2 : v. Generalizing gives us T \^ en let x = 
ei in e 2 : V{6}. v. 

Transitivity of <hmv (Lemma 12 > gives us V{6}. v <h m » < 72 . 

Case HMV Annot: 



v closed v = Va. t T fh mv e : t 
r himv (e • tt) . v 



HMV_ANNOT 



The induction hypothesis gives us T \^ en e : V{6}, b' .t' with 
t'\t /b\\r' /b'] = t. Inverting \^ en gives us T ^ e : Vb'.r'. 
Applying V_InstS gives us T t e : r and we can use 
V_ANNOT to be done. 

Case HMV_lNT: Trivial. 

Case HMV_Gen: 



r ihmv e : (7 a g ftv(T) 
C itimv e . V{a}. <7 



HMV_Gen 



The induction hypothesis gives us T \% en e : a' where a' <h m » 
a. We know a 1 <hmv V{a}. a. In other words, if a' = V{6}. vi 
and <7 = V{c}. W 2 , we have some r such that vi [r/fe] = V 2 - 
By the definition of <h mv we can use these same r to show that 
(7 fahmv V{a, c}. V2~ 

Case HMV_Sub: 



T irimv • (71 <7l ^hmv <72 

r ihmv 0 • (72 



HMV_Sub 



The induction hypothesis gives us T If 1 En e : a' where a <hmv 
<7i. By transitivity of <h m » , we are done. 



□ 



D. Algorithm V 

In this appendix, we use metavariables Q, R , and S to refer to 
substitutions from type variables a to monotypes r. We apply 
and compose these as functions, homomorphic ally lifted from type 
variables to types. 

We suppose the existence of a unification algorithm U, that 
produces a substitution S, with the following properties 

• If S = Ua{ji,T 2 ) then either S(tt) = S(r 2 ) and a D 
dom(S) = 0, or no such S exists. 

• If R(ti) = R(t 2 ) (and a n dom(R) = 0) then there exists 
some S such that R = S o lAa{ri, r 2 ). In other words, unifica- 
tion produces the most general unifier. 

With this function, we can define three mutually recursive, par- 
tial functions that infer the type of an expression in a given context. 
These equations are to be read top-to-bottom. 



Definition 17 (Algorithm V). 

(1) V(T, Ax. e) = (Si, Si(b) — > r) when 

V((T,x:b),e) = (Si.r) 
b fresh 

(2) V(T, ei ea) = ( S 3 ° S 2 ° Si, S 3 {b)) when 

(Si,n) = V(r,ei) 

(S 2 , r 2 ) = V(«Si(r), e 2 ) 
S 3 =W(S 2 (r i),r 2 -4 b) 
b fresh 

(3) V(T, n) = (e, Int) 

(4) V(T, e) = (Si, r) when 

(Si,Va.r) = V*(r,e) 

(i fresh 



(5) V* (T, x) = (e, v ) when 

£: V { a }. v £ T 
<x fresh 

(6) V*(T. lets; = ei in e 2 ) = (S 2 ° Si, V 2 ) when 

(Si, or) = V 9en (T, ei) 

{S 2 ,v 2 ) = V*{(Si(r),x:ai),e 2 ) 

(7) V*(T, e @t) = (Si, vi [r/a\) when 

(Si,\/a.vi) = V*(T,e) 
r closed 

(8) V*(T, (e : v)) = (S 2 o Si, v) when 

v closed 
Va . t = v 
(Si,r') = V(T,e) 

S 2 = Ua(r, t') 

(9) V*(r,e)=V(r,e) 



(10) V gen (T, e) = (S,V{a}.u) when 
{S,v) = V*(T, e) 
a = ftv{v) \ftv{S(T)) 



Lemma 18 (Soundness of Algorithm V). 

1. //V(T, e) = ( S,r ) then S(T) k e : r 

2. //V*(T, e) = (S,v) then S(T) ^ e : v 

3. IfV 9en (T, e) = (S’, <7) then S(T) e : a 

Proof. By mutual induction on the structure of e. In the text of the 
proof, we will proceed in order of the clauses in the statement of 
the lemma, though technically, we should be considering the shape 
of e as the outer-level structure. 

1. Case e = \x.e: By (1), we have V(r,Aa.e) = 
(Si,Si(b) r), where (Si,t) = V((T, x:b), e) and 
b is fresh. We must show -Si(r) h; Xx. e : Si(b) — » r. The 
induction hypothesis tells us S’i(r,a;:6) 1^ e : r. Rewrite 
this as S'i(r), x:Si(b) ^ e : r. V_Abs then gives us the 
desired result. 

Case e = ei e 2 : By (2), we have V(T, ei e 2 ) = (S3 o S 2 o 
Si, S 3 (b)), with several side conditions from the statement 
of V. Let R = S 3 o S 2 o Si. We must show R(T) ^ ei e 2 : 
S 3 (b). The induction hypothesis gives us Si(T) ^ ei : it 
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and S 2 (Si(Y)) V e 2 : r 2 . Furthermore, we know that 
S 3 (S 2 (t i)) = S 3 {t 2 b). 

By the substitution lemma (Lemma 1 1 6| >, we know that 
R(Y) k ei : S 3 (S 2 { T1 )) and R(Y) (fl : 2 : S 3 (t 2 ). The 
first of these can be rewritten to -R(T) f ei : S 3 (t 2 —y b), 
or R{Y) f ei : S 3 (t 2 ) — > S 3 (b). We now use V_APP to 
get -R(F) f ei e 2 : S 3 (b) as desired. 

Case e = n: By (3), we have V(r, n) = (e, Int). We must 
prove r f n : Int, which we get from V_lNT. 

Other cases: By (4), we have V(T, e) = (5 i,t), where 

(Si, Va. t ) = V*(T, e). By the induction hypothesis, we 
have S'i(r) If e : Va. r. By V_InstS, we have Si(T) f 
e : t[t /a] for our choice of r. Choose r = a and we are 
done. 



2. Case e = x: By (5), we know V*(r,*) = (e, v) where 
*:V{a}. v € T. We must show r If x : v. This is direct 
from V_VAR, choosing r = a. 

Case e = let* = eiine 2 : By (6), we know V*(L,let* = 
ei in e 2 ) = (S 2 o Si, v 2 ) where (Si, oi) = V 9e "(r, ei) 
and (S 2 ,v 2 ) = V* ((Si(Y), x:oi), e 2 ). We must show 
S 2 (Si( T)) If let* = ei in e 2 : v 2 . The induc- 
tion hypothesis gives us Si(T) lf e " ei : oi and 
52(5i(r),a::ai) If e 2 : v 2 . Substitution on the former 
gives us S 2 (Si(r)) lf e ” ei : S 2 (cri) and we can rewrite 
the latter as S 2 (Si (T 1 )), *:S 2 (cri) If e 2 : v 2 . V_Let gives 
us our desired result. 



Case e = eo @r: By (7), we know V*(T, eo @t) = 

(Si,ui[t/ 6]) where (Si,Va. Vi) = V*(F, e). We must 
show Si(F) If eo @r : vi[t / b\. The induction hypothesis 
gives us Si (r) If eo : Va. Vi, and we are done by V_TAPP. 

Case e = (eo : v ): By (8), we know V*(T, (eo : v)) = 
( S 2 o Si,v) with side conditions from the statement of 
V, including Va. r = v. We must show S 2 (Si(F)) If 
( eo : v) : v. The induction hypothesis gives us Si(T) f 
e : t' and we also know S 2 (r) = S 2 (r , ). Substitution 
(Lemma 16 1 gives us S 2 (Si(r)) f e : S 2 (t'), which 
can be rewritten as S 2 (Si(L)) f e : S 2 (r). We know 
that v is closed, which means that ftv (t) C a. However, 
a (T dom(S 2 ) = 0, so S 2 (r) = r. We thus can use 
V_Annot and we are done. 

Other cases: By (9), we have V*(r, e) = (S, r) where 

(S,t) = V(r, e). We must show S(T) If e : r. The 
induction hypothesis gives us S'(L) f e : r. We are done 
by V_Mono. 

3. All cases: By (10), we know V 9en (T,e) = (5, V{a}. v) 
where(S,i;) = V*(L,e)anda = ftv(v)\ftv(S(r)).We 
must show S(r) lf c ’ 1 e : V{ a}, v. The induction hypothesis 
gives us S{T) If e : v, and we are done by V_Gen. 



□ 

Lemma 19 (Substitution/generalization). IfH = ftv(v) \ ftv(T) 
and b = ftv(S(v)) \ ftv(S(T)), then ^(Vla}.!;) <h m » 
\/{b}.S(v) 

Proof. We must show 5(V{a}.w) <hmv V{6}.S(w). Simplify 
this to V{c}. 5(v[c/a]) <h m » V{ 6} . S(v) where the c are fresh. 
(They are used to implement capture-avoidance.) By the definition 
of <hmv (HMV_InstG), this simplifies to S' (w[c /a]) [r/c] <h m » 
S(v), for our choice of r. Choose r = S(a), yielding our wanted 
to be S(u[c/a])[S(a)/c] <h m » S(v). Simplifying again yields 
S(u[c/a][a/c]) <h m , S(v), which is the same as S(v) <h m » 
S(v). We are done by reflexivity of <h m , . □ 



Lemma 20 (Completeness of Algorithm V). For all contexts Y and 
substitutions Q: 

1. If <3(L) f e : r, then V(L, e) = (S,r') and there exists R 
such that Q = R o S and t = R(r'). 

2. If Q(Y) If e : v, then V*(L, e) = (S, v') and there exists R 
such that Q = Ro S and v = R(v'). 

3. If Q(Y) lf cn e : o, then V 9en (Y, e) = (S, o') and there exists 
R such that Q = R o S and R(o') <hmv o. 

In the Q = Ro S conclusions above, we ignore any differences on 
type variables that are conjured up as fresh during recursive calls. 



Proof. We proceed by mutual induction on typing derivations. In 
each case, we must provide the following pieces: 

(i) The result of the call to V (such as (S, r')) 

(ii) The substitution R 

(iii) The fact that Q = R o S 

(iv) The fact that, say, r = R(t') 

These pieces will be labeled in each case. 



Case V_Abs: 

T, x:ti k e :t 2 

yt—y V_Abs 

1 L Xx. e : Ti — > t 2 

We know that <5(r),*:ri 1^ e : r 2 . Let T' = Y,x\b (where 
b is fresh) and Q' = [n/6] o Q. Then, we can see that 
V e : t 2 . We thus use the induction hypothesis to get 
V((L, *:&), e) = (S, if ) along with R’ such that Q' = R'oS 
and t 2 = R'{t 2 ). We can thus see that 

(i) V(L, A*, e) = (S,S(b)^ri). 

We have left only to provide R such that Q = R o S and 
n -a r 2 = R(S(b) -f rfi = R(S(b)) —¥ R(t £). 

(ii) Choose R = R' . 

By functional extensionality, Q = R' o S iff Q applied to any 
argument is the same as R' o S applied to any argument. But 
in our supposition that b is fresh, b is outside the domain of 
possible arguments to Q\ thus we can conclude 

(iii) Q = Q' = R' o S, ignoring the fresh b. 

(iv) We can also see that n = Q'(b) by definition of Q' and 
that t 2 = R{t 2 ) by the use of the induction hypothesis. 

Case V_App: 



rtei:n->T 2 Yk e 2 :ri 
r f ei e 2 : 72 



V_App 



The induction hypothesis tells us that V(L, ei) = (5i,r() 
with Ri such that Q — Ri o Si and n — > r 2 = R\(r[). 
Recall that we are assuming <2(L) lj ei e 2 : r 2 , which can 
now be written as Ri(Si( Q)) f ei e 2 : r 2 . We thus know (by 
inversion) Ri(Si( Q)) V e 2 : n. We then use the induction 
hypothesis on this fact, but choosing Q be R\ , not the Q 
originally used. This use of the induction hypothesis gives us 
V(«Si( Q), e 2 ) = (5 2 ,t 2 ) with R 2 such that Ri = R 2 o S 2 
and n = R 2 {t 2 ). We now must find a substitution S 3 that is 
a unifier of S 2 {t[ ) and r 2 — > b for some fresh b. We know 
Ri(rl) = t\ — > t 2 and R 2 {t 2 ) = n. We can rewrite the 
former as i? 2 (5 2 (r()) = n — ¥ r 2 . Choose S 3 = [T 2 /b]oR 2 . 
We see that S 3 (S 2 (r[)) = S 3 (r 2 — > b) as required. We 
now know that W (^(ri), t 2 — > b) will succeed with the most 
general unifier S 3 . We thus know that 

(i) V(r, ci e 2 ) = (S 3 o S 2 o S u S 3 (b)). 

We must now find R. By the fact that S 3 is a most general 
unifier, we know that S 3 = R o S 3 . 

(ii) Choose R to be this substitution, found my the most- 
general-unifier property. 
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(iii) Putting all the facts about substitutions together, we see that 
R o S3 o S2 o Si = Q as needed (ignoring the action on the 
fresh b). 

We must finally show T2 = R(Ss(b)) = Ss(b). 

(iv) This comes from the definition of S3. 

We are done. 

Case V_Int: 



Tk n: Int 

(i) V(T, n) = (e, Int). 

(ii) Choose R — Q. 

(iii) Q = Roe, quite easily. 

(iv) Q(lnt) sure does equal Int. 
Case V_InstS: 

r £ e : Vffl. t 

no other rule matches 



V INT 



rt 



V InstS 



r[r/a] 

The induction hypothesis gives us V*(T, e) = (S,Va.r') 
with R' such that Q = R' o S and r') = Ya. r. Note 

that we have liberally renamed bound variables here to ensure 
that the quantified variables a are the same in both cases. This 
is surely possible because the substitution R' cannot change the 
number of quantified variables (noting that t' must not have any 
quantified variables itself). We thus know R'(t') = r and that 
a (T dom(R') = 0 . 

(i) We can see that V(T, e) = ( S,t '). 

(ii) Choose R to be the [r/a] o R 1 . 

(iii) We can see that Q = RoS as required (ignoring the action 
on the fresh a). 

We have already established that R'(t') = r. We must show 
that R(t') = t[t/o]. 

(iv) This follows from our definition of R. 

We are done. 

Case V_Var: 

a;:V{a}. v € T 

1 J r _ ; _, V_VAR 

T If x : v[r/a\ 

We know x:V{a}. v € < 3 (T). Thus, there exists v' such that 
x:V{a}.w' G T where Q(v') = v. 

(i) Thus, V*(T, x) = (e,v'). 

(ii) Choose R = [r/a] o Q. 

(iii) Clearly, Q = Roe, ignoring the action on the fresh a. 
We must now show that R{v') = u[r/a], 

(iv) This is true by construction of R. 

Case V_Let: 



rf 



ei : <Ji 



, x:a 1 to e2 ■ V2 



T If let x = ei in e2 : V2 



V Let 



°t) 

o 1. 
V2. 



The induction hypothesis gives us V 9en (T, ei) = (Si 
with Ri such that Q = Ri o Si and Ri(a’i) <h m » 

We know (from inversion) that f?i(S'i(r)), x:ai If e2 : 

We also see that Ri(Si(T), x:of) < hmv i?i(Si(T)), x:<j\ 
and thus that 7 ?i( 5 l i(T), x\<j'i) If e2 : V2, by context gen- 
eralization (Lemma QD* which preserves heights of deriva- 
tions. We thus use the induction hypothesis again to get 
V*((Si(r),a;:<Ti),e2) = (S2, v' 2 ) with R2 such that Ri = 
R2 o S2 and V2 = R2(v' 2 ). 

(i) We thus have V*(T, let 2: = ei in e2) = (S2 o Si,^). 

(ii) Choose R = ffe. 

(iii) We can see that Q = R2 o 62 0 Si as desired. 

(iv) We can further see that = V2 as desired. 

CaseV TApp: 



t closed 



rif e :Va.v 



T If e @r : v[t / a\ 



V TAPP 



The induction hypothesis gives us V*(T, e) = (S,v') with 
R' such that Q = R' o S and Ma.v = R'(v'). Because 
the substitution R' maps type variables only to monotypes, we 
know v' must be Va. v" , with R'(v”) = v and a £ dom(R'). 

(i) We thus know V*(T, e @r) = (S,v"[t/cl\). 

(ii) Choose R = R' . 

(iii) We already know Q = R' o S. 

We must show R'(v" [r/a]) = [r/a]. This can be reduced 

to R' (v")[R' ( t) / a] = v\r/ a] by the fact that a qL dom(R). 
Furthermore, we know r is closed, so we can further reduce to 
R'(v")\t/o\ = v[t / o ], 

(iv) But we know R'(v") = v, so we are done. 

Case V_Annot: 



v closed v = V a. r T ^ e : r 
T If (e : v) : v 



V_ANNOT 



The induction hypothesis gives us V(T, e) = (S'i,t / ) with 
Ri such that Q = Ri o Si and Ri(t') = t. We must 
show that r and r' have a unifier. We can assume (by the 
Barendregt convention) that a D dom(Ri) = 0 . We also know 
that ftv(r) C ~a. Thus, Ri (r) = r and Ri is a unifier of t and 
t' . Let S2 = Ua(r, t 1 ) (which is now sure to exist). 

(i) We thus have V*(T, (e : v)) = (&°Si,v). 

(ii) Choose R as determined by the fact that Ri = R o S2 
(gained from the most-general-unifier property). 

(iii) We thus see that Q = R o S2 ° Si as desired. 

(iv) Furthermore, by the fact that v is closed, we get R(v) = v, 
as desired. 

Case V_Mono: 



T ho e : t 

no other rule matches 



r If e : r 



V_MONO 



The induction hypothesis gives us V(r, e) = ( S,t ’) with R 
such that Q = R o S and R(r') = r. 

(i) We see that V*(r, e) = ( S,t '). 

(ii) Choose R to be the one we got from the induction hypothe- 
sis. 

(iii) We see that Q = RoS. 

(iv) We see that R(t') = t. 

Case V_Gen: 



a = ftv(v) \ftv(T) r If e : v 
r lf c " e : V{a}. v 



V_Gen 



The induction hypothesis gives us V*(r, e) = (S, v') with 
R such that Q = R o S and R(v') = v. We know a = 
ftv(R(v'))\ftv(R(S(T))), and let a’ = ftv(v')\ftv(S(T)). 

(i) We see that V 9en (r, e) = (S, V{a'}. v'). 

(ii) Choose R as from the induction hypothesis. 

(iii) We know Q = RoS. 

We must show ^(Vla 9 }. v') <hmv V{a}. v 

(iv) This is direct from Lemma[l 9 | 



n 



Proof of principal types for HMV (Theorem^. By completeness 
of V (Theorem [ 5 }, we have cr' 0 such that F If e ” e : on and 
0 0 <h m , a. By completeness of Algorithm V (Lemma |20), we 
have V 9en (F, e) = (S,a' p ) with R such that e = RoS and 
^(fp) <hm» oo-Leto-p = R(a' p ). By the soundness of Algorithm 
V (Lemma 18 1, we know that S(T) If 6 " e : Op, or equivalently: 
S(T) lf eT1 e : S(a p ). By substitution, we can substitute through by 
R to get r If 6 " e : cr p . By soundness of V (Theorem | 4 |, we have 
r lh mv e : (T p . Recall that cr p <h m » <ro- But we assumed nothing 
about <To- Thus, a p is a principal type for e. □ 
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<71 <b O ' 2 



Higher-rank instantiation 



B_REFL 

T <b T 



V 3 <b Vl V2 <bV 4 „ ^ 

B_FUN 

Vl —¥ V2 <b V3 — > V4 



<t>i[r/b\ < b (j >2 
Va, b. <p i <b Va. <j> 2 



B_InstS 



vi[r/a\ < b v 2 b£ftv(V{a}.v i) 
V{a}. Vi < b V{b}. V2 



B_InstG 



Figure 13. Inner instantiation 



Proof of decidability of System V (Theorem^. All that remains is 
to show that Algorithm V terminates. All cases in Algorithm V 
except for cases (4), (9), and (10) recur on a structural component 
of the input. We can observe that (4) and (9) cannot infinitely recur, 
because one of the other cases is guaranteed to intervene. Because 
(10) recurs from V 3 en (T, e) to V*(F, e), it, too cannot loop. □ 

E. Higher-rank systems: properties of <b 

This section concerns the properties of the first order subsumption, 
higher-order instantiation relation, cri <b <72. For reference this 
relation is repeated in Figure pA] 

Lemma 21 (Monotypes are already instantiated). Ifn <b T2 then 

Tl = T 2 . 



Proof. By inversion. □ 

Lemma 22 (Substitution for instantiation). If o i <b (J2 then 
S(a i) < b S(a 2 ). 

Lemma 23 (Reflexivity for <b ). For all a, a <b a. 

Lemma 24 (Transitivity for <b ). If cti <b <72 and <72 <b <r 3, 
then cri <b a 3. 



Proof. Proof is by induction on H(a 2), where the H function is 
defined as follows: 



H(r) 
H(v 1— > V2) 



H(Va. <p) 
iT(V{a}. v) 



1 

1 + max(Hvi, HV2) 
when at least one of vi and V2 
is not a monotype 
1 + H(<p) 

1 + H{v) 



Note that the H function is stable under substitution (replacing 
variables by monotypes). 



Case (72 is t, a monotype In this case, by Lemma [3T] we know 
that a 3 must also be r. So the result holds by assumption. 

Case (72 is U21 — > V22 By inversion, we know that ai is 
V{a}, b,c.v 11 — > V12 such that V21 <b un[f/5,c] and 
ui2[r/o, c] <b V12. 

We also know that <73 is V{d}. v 3 i —> V32, such that W31 <b 
W21 and W22 <b U32. 

By induction, we can show U31 <b vn[r/a, c] and 
fi2[r/o, c] <b w 32 . 

This lets us conclude that cri <b 02. 



Case (72 is Va. (j > 2 By inversion, we know that cri is V{6}, a, c. <j>i 
such that 4 >i\f/b, c] <b <p2- 

We also know that a 3 is V{d}, Hi. 4 > 3 where a = 01, 02 and 
<t>2\r' /an\ <b (p 3- 

By substitution, we can show that <pi[r/b, c] f I a.f\ <b 

/ 0,2]. 

By induction, we then have (f>i[r/b, c][r , /a2] <b 4 > 3- We can 
then derive cri <b 03 to conclude. 

Case (72 is V{a}. V2 By inversion, we know that cri is V{6}. Vi 
where vi[r/6] <b«2. 

We also know that a 3 is V{c}. v 3 , where V2\r' /~a\ <b v 3 . 

By substitution, we can show that wi[r/6]['f , /o] <b V2\r' /a]. 
Rewrite this as vi[r[r / /a]/ 6] <b V2 [rYo], 

By induction, we have vi [r[T , /a]/6] <b v 3 . 

Therefore we can conclude V{6}. vi <b v 3 . 

a 



F. Higher- rank systems: properties of DSK 
System B 

This section considers the Higher-Rank type systems with deep- 
skolemization, described in Section[6] 

F.l Properties of Prenex conversion 

Lemma 25 (Instantiation and Prenex). If v <b v' and 
prenex(v) = Va. p and prenex (1/) = Vb.p thenVa.p <b 
Vb. p' and b C a. 



Proof. Proof is by induction on v <b v' . 



Case B InstS: 



fi [r/b] < b <j> 2 
Va, b. (pi <b Va. <p2 



B_InstS 



Say that prenex(v) = Va, b, c. p'i where prenex{<p) = 
Vc.p'i. 

This means that prenex (cpi\r / b]) = Va. p'i[r/b] as r do not 
contain quantifiers. 

Say also that prenex{v') = Va, d. (p ' 2 where prenex(cp2) = 
Vl.p'2. 

By induction, we have that pi[r/6] <b p'2 where dCc. 
Therefore we can conclude by B_InstS that 
Va. p'i <b Vb. p'2 

Case B Fun: 



V 3 <b Vl V 2 <bV 4 „ ^ 

B_FUN 

Vl —> V 2 <b v 3 —t V4 

Note that prenex(yi — > V2) = Va. vi — > p2 where Va. p2 = 
prenex( V2) and the a are not free in ui. prenex{v 3 — > V4) = 
Vb.v 3 —y p4 where Vb. p4 = prenex(v 4). So by induction, we 
have that Va. p2 <b V6. p4 and b C a. 

By inversion, we have that p2[r/a] <b p4- From this we can 
derive vi — > p2[r/a] <b v 3 — > pi and then Va. Vi — > p2 <b 
Vb. v 3 — > p 4 - 

Case B_Refl: trivial. 



□ 

Lemma 26 (Prenex instantiates). If prenex (v) = Va. p then 
v < b p. 

Proof. Proof is by induction on v. If v is a monotype, we are done. 
If v = vi — ^ V2, then prenex{v ) = Va.v 1 — » p2 where 
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prenex(v 2 ) = Va. p 2 - By induction, we know that U 2 <b p, so 
by B_FUN, we have t>i — > v 2 <b vi — > p. 

If v is a specified polytype, of the form Va. cp , then 
prenex (v 2 ) = Va, b. p ' 2 where prenex{(j>) = V b. p' 2 . By induc- 
tion, we know that p[ <b p 2 - We can then show that Va, b. p[ <b 
p 2 by B_InstS (and instantiating variables with themselves.) □ 

F.2 Properties of DSK subsumption 

Lemma 27 (Substitution for higher-rank subsumption). Ifv i < dS k 
v 2 then S(v 1 ) <dsk S(v 2 ). If o\ <dsk v 2 then S(oi) <dsk S(v 2 ). 

See Vytiniotis et al. m Lemma 2.7. 

Lemma 28 (Reflexivity for < ds k )• For all v, v < d sk v. 

Proof. Vytiniotis et al., |26j Lemma 2.21. □ 

Lemma 29 (Transitivity for < dS k )• Ifv i < ds k v 2 and v 2 < dS k v 3 , 
then vi <dsk V 3 . 

Proof. Vytiniotis et al., lf26l Lemma 2.22. □ 

Lemma 30 (Single skol admissible). If ai <dsk v 2 then cr\ < dS k 
Vc. v 2 (when c are not free in cri). 

Proof. Proof is by induction on o\ < dS k v 2 . 

Case DSK_Refl: Direct by DSK_InstS. 

Case DSK_Fun: 

V 3 <dsk Vl V 2 <dsk p4 _ 

DSK_Fun 

vi -»• v 2 <* sk v 3 -A P4 



Case OL_B_AFun: By induction. 

Case OL_B_AInstS: 

(pi [r /a] < 0 i r />2 b £ ftv(Va. (pi) 
Va. (p i < 0 | Vb. (ft 2 



OL_B_AInstS 



By induction we know that <j > i [r/b] <d S k <t> 2 - We want to show 
that Va. 01 <dsk V6. (j> 2 . Say prenex (<p 2 ) = Vc. p 2 , then by 
DSK_Inst it suffices to show that <f > i [r'/b] <dsk p 2 - Note that 
as Vc. p 2 <dsk p 2 , by transitivity, we can reduce this to showing 
<t>i [r/6] <dsk prenex (4> 2 ). 

We can finish, again by transitivity, by showing via Lemma [32] 

that (j> 2 <dsk prenex (iff). 



□ 



Corollary 34 (DSK Subsumption contains Instantiation). lfv\ <b 
v 2 then vi <dsk v 2 . 

Proof. See above and Lemma|46| □ 

Lemma 35 (Transitivity of Higher-Rank subsumption I). Ifoi <b 

o 2 and o 2 <dsk V 3 , then 01 <dsk v 3 . 

Proof. Follows from Lemmas |29| and [34| □ 

Lemma 36 (Transitivity of Higher-Rank subsumption II). If 

01 <dsk V2 and v 2 <b V3, then o\ < dsk v 3 . 

Proof. Follows from Lemmas [29|and[34| d 

F.3 Substitution 



Say prenex(v 4 ) = Vb. p. By inversion, we know that vi — > 
V2 <dsk V3 —> p. We also know that prenex (Vc. v 3 — > V4) = 
Vc, b. v 3 — > p, so we can conclude with DSK_Inst. 

Case DSK_Inst: 



prenex(v 2 ) = Vc.p 2 
^i[r/a][r'/b] < dS k Pi 
V{a}, b. fi <dsk v 2 



DSK_Inst 



We note that prenex(Vc. v 2 ) = Vc, b. p 2 , so we can just apply 
DSK_Inst. 

Case SB_Inst: 



prenex (v 2 ) = Vc.p 2 
fi[T/a][r'/b\ < 3sk P2 
V{a}, b. (pi <dsk v 2 
Similar reasoning to DSK_Inst. 



DSK_Inst 



□ 

Lemma 31 (Monotypes are instantiations). If o <d Sk r then 

o <b T. 

Proof. Proof is by induction on o < ds k r. In each case the result 
holds directly by induction. □ 

Lemma 32 (DSK and prenex). For all v, we have v <dsk 
prenex( v). 



Although a more general substitution property is true for these sys- 
tems, in this development we need only substitute for generalized 
type variables. Therefore, we state these lemmas is more restrictive 
forms. 

Lemma 37 (Substitution for System B). Assume that the domain 
of S is disjoint from the variables ofT or the free type variables of 
e. 

1. IfT lb e =4> cr then T Ig e =4> S(o) 

2. IfT lb e <= v then T ^ e <= S(v) 

Lemma 38 (Substitution for System SB ). Assume that the domain 
of S is disjoint from the variables ofT or the free type variables of 

e. 

1. IfT bn, e => (p then T e =4- S((p). 

2. IfT lf b e =4> v then T lf b e => S(v). 

3. IfT If™ e =4- o then T e =4- S(o). 

4. IfT ifb e <= v then T e <= S(v). 

5- IfT kb e A= p then r Ijb e -4= S(p). 

F.4 Soundness of syntax-directed system 

Because of the differences between the syntax-directed and the 
declarative system, we need the following lemma about System B 
to prove the soundness of System SB. 

Lemma 39 (Prenex System B). IfTY^e-^p and prenex (<p) = 
V~a. p then F 1^ e <= <p. 



Proof. Proof is by induction on v. 



□ Proof. Case B_DAbs 



Lemma 33 (DSK Subsumption contains OL Subsumption). If 

vi < 0 i v 2 then vi < dS k v 2 . 

Proof. Proof is by induction on the derivation. 

Case OL_B_ARefl: Trivial. 



T, xwi lb e 4= v 2 
T ^ Xx. e 4= vi — > v 2 



B_DAbs 



In this case, because we are pushing in p, we have v 2 = p 2 . We 
also know that prenex (cp) = Va. vi — > p 2 , so <p must be of 
the form ui -> U 2 . 
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Write V2 as Vd\.cp 2 . We also know that prenex(v 2 ) = 
Vai, a 2 .p 2 where prenex (</> 2 ) = Va 2 . P 2 • 

By induction, we have F,a;:vi ^ e <= cp 2 By (repeated) use 
of B_Skol, we have T, x:vi ^ e <= Vd. cp 2 By B_DAbs, we 
can then conclude F ljj \x. e •<= v\ — >• Va. 02, which is what 
we wanted to show. 

Case B_DLet 



T ^ ei =A cri T, x\oi ^ e 2 <= v 
F ^ let x = ei in e 2 <= v 



B_DLet 



This case holds by induction. 

Case B_SKOL This case is impossible, as the conclusion does not 
have the form cp . 

Case B_Infer 



r lb e =>(T1 (71 <dsk V 2 

T ^ e 4= V 2 



B_Infer 



Here we know that V2 is p. By inversion of a <dsk p, we have 
a = V{ai}, 61. <j>2 where where prenex(cp 2 ) = Vc. p and 
P 2 [r/ai] [r'/6i] <dsk P- 

However, as we also have prenex (cp) = Va. p , we can use the 
same information to conclude, a < bS k cp, and then use B_lNFER 
to show that T l-g e ■<= 0. 

□ 



Proof Soundness of System SB Lemma[7]states: 

1 . If T lj b e => cp then T Ig e => cp. 

2. If T lf b e => v then T lg e => v. 

3. If T If™ e => a then F Ig e =>■ a. 

4. If T lf b e •<= v then Y e <= v. 

5. If T lj b e <= p then V Ig e <= p. 



Proof. Most of the cases of this lemma follow via straightforward 
induction. Cases SB_Spec, and SB_Var are similar to the cases 
for V_InstS and V_VAR, so are not shown. We include selected 
cases below. 



Case SB_Annot: 

Tht) v = Va. i 



r Ifb (e : w) =4> w 

By induction we know that T, d Ig e 
can conclude T Ig (e : v) =4- v. 

Case SB Infer: 



SB Annot 



cp. By B_ANNOT, we 



r 4 e => Vi Vi <dsk p2 

no other rule matches 

T lib e <= p 2 



SB_Infer 



By induction, we know that r Ig e 4 «i. We would like to 
show that Y e <= p 2 . This follows immediately by B_lNFER. 
Case SB_DeepSkol 



prenex(v) = Va.p 
a £ uars(r) Y lib e <= p 



r & 



SB_DeepSkof 



By induction, we have T Ij e 4= p. Note that if prenex(v) = 
Vd. p and v is of the form Vd'.cp, then, by definition 
prenex (cp) = Vd" . p and a = a', a". By the prenex 

lemma[39] we know that Y Ig e 4= cp. We can then use multiple 
applications of rule B_Skol to conclude F Ig e 4= Vd' . cp. 



□ 



F.5 Completeness of syntax-directed system 
Lemma 40 (Context Generalization). Suppose T' < b T 

1. IfY l^b e =$■ cp then there exists cp' < b cp such that r ; hr b e =4> 

2. If r lg b e => v then there exists v' < b v such that T' lf b e =4- 

v' . 

3. IfY Ifb" e => o then there exists o' < b o such that Y' If™ 
e => o'. 

4. IfY lf b e <= v and v < b v' then T' (f b e 4= v‘ . 

5. IfY la, e 4= p and p < b p' then T' Ig, e 4= p. 



Proof. Proof is by induction on derivations. 
Case SB_Abs: 

T, x:t Ifb e =£- v 



Y Ijb Xx. e 



SB_Abs 



By induction, we know that T', x:t (f b e => v' for v' < b v. 
Therefore, F' lib Xx. e => r — > v' and, by SB_Fun, r — > 
v' < b t — > v. 



Case SB_Int: 
Trivial. 

Case SB InstS: 



r 1^ n =£- Int 



SB INT 



r 4 e =>V a. cp 

no other rule matches 

r lib e =A cp[r /a] 



SB_InstS 



By induction, we know that Y (j b e =4- v' where v' < b 
Vd. <p. By inversion, we know that v must be of the form 
Vd, b.cp' where cp'\f'/b] < b <p. By SB_InstS, we can con- 
clude T 4 e =4 (cp'[r' /b])[r/d]. We also need to show 
that (cp'[r' / b])[r/d] < b cp\f/a], which follows by substitution 
(Lemma|22|>. 

Case SB_Var: 



c:V{a}. v G Y 



r^ b 



SB_Var 



x =4- v[t/ a] 

We know that x:o £ T, where o < b V{a}. v. So by inversion, 
o must be V{6}.i/ such that v'[r'/b] < b v. Therefore, by 
substitution lemma 
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v'[r' /b][r/d\ < b v\r/d\. As we know 
that the d are^not free in v' , we can rewrite the left hand side as: 
/d]/b\, and choose those types in the use of SB_Var. 

Case SB App: 



r lib ei => Vi 



V2 



r tb e2 



: wi 



SB_APP 



r lf b ei e2 => V 2 

By induction we have F' li b ei => cp such that cp <b v 1 — » V2. 
By inversion, this means that cp must be of the form v 1 — > v ' 2 
where vi <b«J and v ' 2 <b«2. 

By induction, we have T' lj b e2 <= v[. So we can conclude by 
SB_APP. 

Case SB Let: 



rC 



ei 



<71 



r, x:ox h, e 2 



V2 



Y If. let x = ei in e 2 



SB Let 



V2 



By induction F' lfb * ei =4 <Ji for o[ < b ai. By induction 
(again), T', x\oi lf b e2 => v'2 for t>2 <b V2- So we can conclude 
by SB_Let. 

Case SB_TApp: 



F hr 



r£ 



■ Va. v 



F lfb e @r ; 



SB TAPP 
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By induction r' 4 e => v' where v' <b Va.v. By inversion, 
v' is of the form Va.vi where vi <b v. By substitution, 
vi [t / a] <b v[t/ a}. 

Case SB_Annot: 



r I- v v = Va. (f> r, a 4 e <= 4> 

r 4 ( e : v ) =► v 

By induction, we have r',o 4 e •<= </> , 
SB_ANNOT to conclude F' 4 e v. 

Case SB_Phi: 



SB_Annot 
so we can use 



r lib e =4- </) 

no other rule matches 

r 4 e ^ ^ 

Holds directly by induction. 

Case SB_Gen: 



SB_Phi 



r 4 e ^ u a = ftv{v) \ vars(F) 

rr^v{«}.« 



SB_Gen 



By induction, we have T' 4 e v' for v' <b v. Let b = 
ftv(v') \ vars(r). We want to prove that V{6}. v' <b V{(i}. v. 
This holds by B_InstG, choosing r = ~a. 

Case SB_DAbs: 



r, x:vi 4 e <= pi 
F lib Ax. e <= vi — > p 2 



SB_DAbs 



Let F' <b r and vi — > p 2 <b v' be arbitrary. By inversion, we 
know that v' is v[ — > v 2 where v[ <b vi and p2 <b«2- 
By inversion, we know that v' 2 must be of the form p 2 . as <b 
cannot introduce specified quantifiers. 

By induction, we know that F', x:v[ 4 e p 2 - 
So we can conclude by SB_DAbs. 

Case SB_Infer: 



r 4 e A Wl Vl <dsk p2 

no other rule matches 

L Ijb e <= p2 



SB_lNFER 



Let F' <b F and p 2 <b p' be arbitrary. By induction, we 
know that F' 4 e => v' for v' <b v\. We want to show that 



v' <dsk p' ■ This holds by lemmas [35] and 36 
Case SB DLet: 



T 4" ei =>■ err F, x:ai 4 e2 <= p 2 
T lib let x = ei in e 2 <1= p 2 



SB_DLet 



Let r' <b T and p 2 <b p' be arbitrary. By induction, we 
have r' 4" ei =A <r[ for a[ <b or. By induction (again), 
r', x:a[ 4 e 2 <= p' ■ So we can conclude by SB_DLet. 

Case SB_DeepSkol 



prenex(v ) = \/a.p 
a £ vars(T) F lib e <= p 



r 4 



SB_DeepSkol 



Let r' <b r and v <b v' be arbitrary. Let prenex{v') = 



Va' . p' . By Lemma 26 we know that p <b p' . 



So by induction, F'Tjb e <= p‘ 



Therefore, we can use SB DeepSkol to conclude. 



□ 



Proof. Most cases of this lemma either follow by induction, or are 
analogous to the completeness lemma for System V. 



Case B VAR 



x\a € r 
F l^ x =$• o 



B VAR 



Suppose a is for the form V{ a} . v. Then we use a to instantiate 
the variables a. We know these a are not free in T by the 
Barendregt convention. It may be the case that generalization 
quantifies over more variables, i.e. a C a' = ftv(v)\vars(F), 
leading to a more general result type. However, that is permitted 
by the statement of the theorem. 

Case B_Abs 



T, x:t 1^ e => v 
F l^ Ax. e =$■ r — > v 



B_Abs 



The induction hypothesis gives us F, x:r 4" e V{a}.i/ 
where V{a}.t/ <b v. Inverting 4" gives us T,x:t 4 e =► 
v' and inverting <b gives us v' [r/a] <b v. We can then 
substitute and use SB_Abs to get F 4 Ax. e => r — > t/fr/a]. 
Generalizing, we get V 4" Ax. e => V{a, h'}.t — > v'[r/a] 
where the new variables ~a! come from generalizing r and the 
t' . We are done because (r — ¥ v')\t/h\ <b r — > v and so 
V{a, a 1 }, t — > v' <b t — > v 
Case B_App 



F lb ei vi — > V 2 r ^ e 2 



Vl 



T L ei e 2 



B App 



Vl 



By induction we have T 4” ei => a for some a <b fi — > V 2 - 
So by inversion o = \/{~a},b.v'i — > v 2 , where (v[ — > 
v' 2 )\r / i£\\t' / b] <b Vi -> v 2 and vi <b v'^fr / b\ and 
v' 2 \r /b\ < b v 2 . 

Also by inversion of 4"> we know that T 4 ei 4 V6. v'i — > 
v 2 and that the a are not free in T or ei . 

By substitution, we have T 4 ei =>■ V6. ( vi ->■ v 2 )[t/o\ 

And by SB_InstS, we have T 4 e i =► Wi —>■ 
v' 2 )[r/a][r'/b\. 



By induction we have T 4 «2 <= v[ and by lemma 
know that F 4 e 2 -4= v'i \r / h]\t' / b\. 

So we can conclude F 4 e i e 2 <= v ' 2 \t /1i\\t' / b\. 

CaseB Let 



53 



F l^ ei cti T, x:cti l^ e 2 
T L let x = ei in e 2 => a 



B Let 



The induction hypothesis gives us F 4" e i °i with a[ <b 
a i. The induction hypothesis also gives us T, xkji 4" e 2 =^ 
a 2 with a 2 <b <x 2 . Use Lemma[53|to get F, x:a[ 4" e 2 a 2 
where a 2 <b <x 2 . 

Let a 2 = V{6}.w where b = ftv(v ) \ uors(r). Inverting 
4” gives us r,x:<Ti 4 e 2 v. We then use SB_Let 
to get T 4 l eta; = ei in e 2 => v. Generalizing gives us 
F 4" l et x = ei in e 2 =>■ Vj_b|. v. 



Transitivity of <b (Lemma 24 1 gives us V{6}. v <h^ 
Case B_Int 



a 2- 



Fh b n: 



Int 



B Int 



Trivial. 

CaseB TApp 



Proof of Completeness of System SB Lemma[8]states: 

1. If F 4 e => o then T 4" e => a' where a' <b a. 

2. If T 1^ e 4= v then T 4 e 4= v. 



r I- r Fte=>Va.r) 

— B_TAPP 

T lg e @r => v[t/ a\ 

The induction hypothesis (after inverting 4") 8 ives us r 4 
e => Va. v' , where b = ftv(y a. v')\vars(T) and v'[r/b] <b 
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v. Applying SB_TAPP gives us T lf b e @r => v'[t/o \ , 
and SB_Gen gives us T If™ e @r => \{c}.v'[t/o\ 
where c = ftv(v'[r/ a]) \ vars(T). We want to show that 
V{c}. v'[t/cl\ <b v[t / a], which follows when there is some 
r' , such that v'[r / a]\f' /c] <b v[t/ a\. 

This is equivalent to exchanging the substiution, i.e. finding a 
t' such that v' [r‘ ' / c] [r / a] <h v [r/ a] . 

By Substitution (Lemma |22|, we have v'^r/b]\r/d\ <b 
v[r/a]. We also know that the b are a subset of the c. So we 
can choose t' to be t for the b, and the remaining c elsewhere, 
and we are done. 

Case B_Annot 



T I- v v = Va.(j> T, a fb e <= cj> 
r ^ (e : v) => v 



B_ANNOT 



By induction, we have T, a lf b e <= (j). We can conclude by 
SB_ANNOT. 

Case B_Gen 



L fb e =>■ a a (jL mrs(T) 
T ^ e => V{a}. a 



B_Gen 



The induction hypothesis gives us T If™ e => o' where a' <b 
a. We know a' <b V{a}. a. In other words, if a' = V{6}. Vi 
and a = V{c}. V 2 , we have some r such that vi [r/b] = vi. 
By the definition of < b we can use these same r to show that 
o' <b V{a, c}. V2- 
Case B_Sub 



T fb e =!> cri CTi <b <72 
V^e=>a 2 



B_Sub 



The induction hypothesis gives us T If™ e => o' where 
a' <b o\. By transitivity of <b , we are done. 

Case B_DAbs 



T, x:vi fb e <= V 2 
T ^ Xx. e <= vi — > V 2 



B_DAbs 



By induction, we have that T, x\Vi lf b e 4= i> 2 - 

By inversion, we have prenex(v 2 ) = Va. p and Y,x\v\ Ig, 

e <= p. 

Therefore by SB_DAbs, we can conclude T lf b Xx. e <= v\ — > 
p, and by SB_DeepSkol, we know T lf b Xx. e <= V\ — > V 2 - 

Case B_DLet 



T ^ ei => <Ji T, ^ e2 ^ v 
T ^ let x = ei in e 2 w 



B_DLet 



By induction we have T, x:oi lf b e 2 <= v. Also by induction, 
there is some a 1 <b <ti, such that T If™ e => o' . By context 
generalization, we know that Y^x'.o’^ lf b e 2 4= v. So we can 
use SB_DLet to conclude. 

Case B_Infer 



T ^ e => < 7 i <71 < dsk V2 

T ^ e •<= V 2 



B_lNFER 



In this case, we know that rri < dsk V 2 - We would like to show 
that T Hr b e V 2 - Suppose prenex(v 2 ) = Va. p, by rule 
SB_DeepSkol, it suffices to show T li b e <= p. 

Suppose <7 1 is V{6}. vi. By inversion of <71 < dsk V 2 , we know 
that vi[r'/b] < dsk p. 

By induction, there is some a' <b <ti, such that T If™ e => o' . 
By inversion of If™ we know that < 7 ' is of the form V{<i}. v' 
and that T lf b e => v'. 

By inversion of a' <b <71, we know that v'\t/Ti\ < b vi. By 
substitution, this means v' [ t / o\[t' / b\ < b vi [r'/b\. By the 



Barendregt convention, the b can appear in the t but not in 
v' . So we can rewrite this substitution as w / [r[r , /6]/a]. We 
can then substitute (as the a were generalized) T lj b e =£■ 
w'[r[r'/6]/a]. 

By transitivity (Lemma|35jl we know that v'\t\t' /b\/li\ < dsk p. 
So we can conclude T hit, e 4= p using SB_lNFER. 

Case B_Skol 



T l|; e 4= v a t)ars(T) 
T ^ e 4= Va. v 



B_Skol 



By induction, we have T lf b e <= v. We would like to 
conclude T H? b e *1= Ma.v. By inversion, we have T lib 
e p where prenex(v) = Va. p. However, this means that 
prenex(Va.v) = Va, a. p. Therefore, we can conclude using 
SB_DeepSkol. 



n 



Unlike System V, we have not shown that the algorithm deter- 
mined by System SB computes principal types. We believe that all 
of the complexities of that proof are already present in the corre- 
sponding proofs about System V and the extensive proofs for the 
bidirectional type system of GHC 1: 281 . 
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Vl <o| l>2 



OL_B_ARefl 

T <o| T 



V 3 <ol Vl V 2 <d V4, 
Vl —¥ V2 <ol V3 — >• V4 



OL_B_AFun 



</>i [r/a] <oi <t>2 b £ ftv(\/a. 4 >i) 
Va. <j)i < 0 i V6. (j>2 



OL_B_AInstS 



r e =A a 



Synthesis rules for System B 



x\a £ r 
r ^ x => a 



OL_B_Var 



Figure 14. Subsumption in the Odersky-Laufer type system 



T, x:t ^ e => v 
T ^ Xx. e => t — » v 



OL_B_Abs 



G. Higher- rank systems: OL variant 

This section concerns the properties of a higher-rank type system 
that does not include deep skolemization and provides an alterna- 
tive treatment of scoped type variables. 

We present this system mainly for comparison with Dun- 
field/Krishnaswami 0 (see below). However, it also shows that 
the deep-skolemization relation is not an essential component of 
our type system. Instead of <dsk, it uses the Odersky-Laufer sub- 
smption relation shown in Figure[T4| 

The only difference between this system and the DSK version 
of System B, is the use of this relation in the B_lNFER rule and the 
treatment of scoped type variables in the B_ANNOT and B_Skoe 
rules. See Figure |T5l The syntax-directed version of the system is 
in Figure[l6] It differs from System SB in that it again uses the < 0 | 
relation, introduces scoped type variables at SB_SKOL and does 
not do deep-skolemization in the checking rule for polytypes. 

A note on scoped type variables The alternative mechanism for 
scoped type variables leads to some “strange” binding behavior. In 
particular, if y has the following type in the context 

y : (Va. a — / a) — / Int 

then the expression 

y (Xx. ( x : a)) 

would be well typed, even though the specification of y’s type could 
be very far from this application. Likewise, we only introduce top- 
level variables into scope. In particular, 

( Xy . Xx. (x : a) : Int — » Va. a —v a) 

would be well-typed if we introduced scoped type variables in rule 
B_Skol, but is rejected by system B. 

G.l Properties of OL subsumption 

Lemma 41 (Substitution). Ifv i < 0 | V 2 then S'(vi) < 0 i S( V 2 ). 

Proof. Vytiniotis et al., Lemma 2.1 dl26l ) □ 

Lemma 42 (Reflexivity for < 0 i ). For all v, v <oi v. 

Proof. Vytiniotis et al., Lemma 2.2 (j26i) □ 

Lemma 43 (Transitivity for < 0 | ). Ifv i < 0 i V 2 and V 2 <oi V 3 , 
then vi < 0 i V 3 . 

Proof. Vytiniotis et al., Lemma 2.3 (|26|) □ 

Lemma 44 (Single skol admissible). Ifv 1 <oi V 2 then vi <oi 
Vc.v 2 (when c is not free in vi). 

Proof. Proof is by induction on vi < Q i V 2 - □ 



r ^ ei => vi — > V2 r e2 4 = vi 

T ^ ei e2 => V 2 

r ^ ei => cri r, x:oi ^ e2 => o 



T F let x = ei in e2 



OL B APP 



OL B Let 



F ^ n => Int 



OL_B_Int 



rhr r^e=>Va.r> 
r ^ e @r => v[r/ a\ 

ri-w r e <= v 



r ^ (e : v) => v 

r ^ e =^> o a qL pars(r) 
r t e =4- V{a}. a 

r ^ e = 4 - 01 or <b 02 

r h: e => a 2 



OL_B_TApp 



OL B Annot 



OL B Gen 



OL B Sub 



T L e <= v 



T, xwi ^ e <= V2 



T ^ Xx. e 4 = vi — > V2 

T ^ ei =4 (7i F, x:o\ (5 e2 <= v 
T ^ let x = ei in e 2 <4 u 

V, a ^ e <= v a ^ uars(r) 
r ^ e <= Va. v 



OL_B_DAbs 



OL_B_DLet 



OL_B_Skol 



r ^ e =4 Vl Vl <oi V 2 
r L e - 4 = V2 



OL_B_lNFER 



Figure 15. Declarative specification of System OL-B 



26 



2015/7/10 



Lemma 45 (Monotypes are instantiations). Ifv < Q i rthenv <b r. 



T lib e => <j> 



T, x:t lf b e => u 
T lj b A®. e => r — >■ u 



OL_SB_Abs 



Proof. Proof is by induction on v < 0 | t. In each case the result 
holds directly by induction. O 



F Ijb n => Int 



OL_SB_lNT 



Lemma 46 (Subsumption contains instantiation). Ifv i < b V 2 then 
Vl < 0 | U 2 . 



r 4 e => Va. (f> 

no other rule matches 

r tb e => </>[r/a] 
r 4 e =>■ v 



OL_SB_InstS 



Proof. Proof is by induction. 

Case B_Refl: Trivial 
CaseB_FUN: By induction. 
Case B_InstS: 



®:V{a}. v £ T 
r 4 * => v[r/a\ 



OL_SB_Var 



r l?b ei => Vl — > V2 r lf b 62 <= Vl 
r lf b er e2 =$■ V2 



OL_SB_App 



<M r/b] < b <j > 2 
Va, 6. (j > i < b Va. </> 2 



B_InstS 



By induction we know that </>i [r/6] <oi <j> 2 - We can rewrite this 
as <f>i [a/a][r/b] < Q | </> 2 , and conclude by DSK_Inst. 



T If™ ei =>■ <Ji T, x:ai | b e 2 =>■ v 2 
T lf b let x = ei in e 2 => u 2 



OL_SB_Let 



r h r r 4 e =► Va. v 
T lf b e @r => v[t/ a] 



OL_SB_TAPP 



Th w r lf b e 4= u 

r lfb (e : w) =^> w 



OL_SB_Annot 



r lib e => <f> 

no other rule matches 
— OL_SB_PHI 

r tb e => 0 



r If™ e =>• a 



T lf b e => v a = ftv(y) \ vars(T) 
Tlf™ e=>V{a}.u 

T tb e <= <j> 



OL_SB_Gen 



T, x:vi lfb e <= V 2 



T Ijb A®, e <= Vi 



v 2 



OL_SB_DAbs 



r If™ er =>■ tji r, x-.fJi lib e 2 4= 4 > 2 
T Ijb let x = ei in e 2 <= 4 > 2 



OL SB DLet 



T lfb e =A Ur Ur <oi cj > 2 

no other rule matches 

r ijb e <= 4>2 



OL_SB_lNFER 



T, a ijb 6 4= 4> a 4 L uars(T) 
r 4 e <= Va. 0 



OL_SB_Skol 



Figure 16. Syntax-directed specification of System OL-SB 



□ 



Lemma 47 (Transitivity of Higher-Rank subsumption I). Ifv 1 <b 

U 2 and U 2 <oi U 3 , then ur <oi U 3 . 



Proof. Follows from Lemmas [43] and [46| □ 

Lemma 48 (Transitivity of Higher-Rank subsumption II). If 

ur <01 U 2 and v 2 <b U 3 , then ui < Q | U 3 . 



Proof. Follows from Lemmas [43] and[46| 



B 



G.2 Substitution 

Lemma 49 (Substitution for System B). Assume that the domain 
of S is disjoint from the variables ofT or the free type variables of 
e. 

1. IfT I j e=l(j then T Ig e =4- S(a) 

2. IfT e <= v then T ^ e <= S(v) 

Lemma 50 (Substitution for System SB ). Assume that the domain 
of S is disjoint from the variables ofT or the free type variables of 
e. 

1. IfT bn, e =4- 4> then T e =4- S(4>). 

2. IfT lf b e => v then T lf b e => S(v). 

3. IfT If™ e => a then T If™ e =4- S(a). 

4. IfT lf b e <= v then T lf b e <= S(v). 

5. IfT hr b e <= 4> then T hf b e <= S(4>). 

G.3 Other properties 

Lemma 51 (Monotypes are uninformative). IfT lg e 4= t then 

T t e => t. 



Proof. This follows because of the four checking rules, the first 
two have identical monotype versions, the third doesn’t apply to 
monotypes and the last follows by B_SUB and the fact that r is an 
instantiation of cr (lemma |45|>. □ 
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G.4 Soundness of System SB 
Lemma 52 (Soundness of System SB). 

1. IfY hr b e => 0 then Y (g e =4- (j>. 

2. IfT 4 e => v then Y ^ e => v. 

3. IfY lf b " e => a then r ^ e => a. 

4. IfY 4 e <= v then Y ^ e <= v. 

5. IfY hr b e <= cj) then r ^ e <= cj>. 



Proof Most of the cases of this lemma follow via straightforward 
induction. Cases SB_Spec, and SB_Var are similar to the cases 
for V_InstS and V_VAR. 



Case SB_Infer: 



r 4 e => vi vi < 0 i 4> 2 

no other rule matches 

r lib e 4= <j >2 



OL_SB_Infer 



By induction, we know that Y ^ e => vi. We can show that 
F ^ e <1= 02 by B_lNFER. 

Case SB_Skol 



r, a ^ e 4= 0 a fL ?;ars(r) 
r e <t= Vo. 0 



OL_SB_Skol 



By induction, we have Y e <= p. We can immediately use 
rule B_SKOL to conclude. 



□ 



G.5 Completeness of SB 

Generalizing and specializing syntax-directed derivations 

Lemma 53 (Context Generalization). Suppose r' < b T 

1. If r Ijb e = 4 - 0 then there exists < b 0 such that r ; lj b e =4 
</>'■ 

2. IfY 4 e => v then there exists v' <b v such that r' 4 e => 
v' . 

3. IfY lf b ” e => a then there exists u' < b cr such that T' lf b ” 
e => o'. 

4. IfY 4 e <= v and v < b v' then r' 4 e <= v'. 

5. If r lib e •<= 0 and 0 < b <j>' then Y' lib e •<= 0. 

Proof. Proof is by induction on derivations. 



that (0 / [r , /6])[r/a] < b 0[r/a], which follows by substitution 
(Lemma|22|>. 

Case SB_Var: 



x:V{a}. w£ T 
r 4 * => t>[r/a] 



OL_SB_VAR 



We know that x:cr £ T, where a < b V{a}. v. So by inversion, 
a must be V{&}.t/ such that i /[r'/ft] < b v. Therefore, by 



lemma 



22 



v'l' f' /b\^f/H\ <b w[r/a]. As we know that the 
a are not free in v' , we can rewrite the left hand side as: 
/d\/b\, and choose those types in the use of SB_Var. 

Case SB App: 



T Ijb ei => v\ — > v 2 T 4 e2 v\ 
Y lf b ei e2 =$■ v 2 



OL_SB_App 



By induction we have T' 4 ei =F 0 such that 0 < b vi — ► t>2- 
By inversion, this means that 0 must be of the form v'\ — > v 2 
where V\ < b v[ and v 2 <b v 2 . 

By induction, we have F' 4 e 2 •<= v'\ [r/6]. So we can 
conclude by SB_APP. 

Case SB_Let: 



r (f b n ei => (Ti r, x:ai lf b e 2 => v 2 
Y 4 let x = ei in e2 => v 2 



OL_SB_Let 



By induction T' 4™ ei =£■ a[ for a[ < b o\ . By induction 
(again), T', x\a[ 4 e2 =4 'i4for'i4 <b v 2 . So we can conclude 
by SB_Let. 

Case SB_TApp: 



n-r F 4 e Va. v 
r lf b e @r =£- v[r / a] 



OL_SB_TAPP 



By induction F' 4 e v' where v' < b Va. v. By inversion, 
v' is of the form Va.t>i where v\ < b v. By substitution, 
vi [r /a] < b v[t/o\. 

Case SB_Annot: 



r h v r 4 e f 

F lfb (e : w) => w 

Holds directly by induction. 

Case SB_Phi: 



OL_SB_Annot 



Case SB_Abs: 



T, x-.T lf b e => v 
Y 4 Ax. e =4 t — > v 



OL_SB_Abs 



By induction, we know that T', x:r 4 e => v' for v' <b v. 
Therefore, T' 4 Ax. e => t — > v' and, by SB_FUN, r — > 
v' <b t — >■ v. 

Case SB_Int: 



r Ijb n =£■ Int 



OL_SB_lNT 



Trivial. 

Case SB_InstS: 



r lf b e ^ Va. 0 

no other rule matches 

r lj b e => 0[r/a] 



OL_SB_InstS 



By induction, we know that Y lf b e => v' where v' <b 
Va. 0. By inversion, we know that v' must be of the form 
Va, b.(f>' where 0 , [r , /6] < b 0. By SB_InstS, we can con- 
clude r 4 e => (0 , [r , /6])[r/a']. We also need to show 



T l?b e => 0 

no other rule matches 
OL_SB_Phi 

r Ijb e => 0 

Holds directly by induction. 

Case SB_Gen: 



r lf b e => v a = ftv(v) \ vars(Y) 
Y tf b " e => V{a}. v 



OL_SB_Gen 



By induction, we have r' lf b e => v' for v' <b v. Let b = 
ftv{v') \ xars(F). We want to prove that V{ 6} . v' <b V{a}. v. 
This holds by definition. 

Case SB_DAbs: 



r,x:ui 4 e -t= t>2 
T ^ Ax. e vi — > v 2 



OL_SB_DAbs 



Let r' < b r and v\ — > v 2 <b v' be arbitrary. By inversion, 
we know that v' is v[ — > v 2 where v\ < b fi and v 2 < b v 2 . 
By induction, we know that Y' ,x\v'\ 4 e ^ v 2 ■ So we can 
conclude by SB_DAbs. 



28 



2015 / 7/10 



Case SB_Infer: 



r f b e => vi vi <oi 02 

no other rule matches 

T lit, e <= 02 



OL_SB_lNFER 



Let r' <b L and 02 <b <p' be arbitrary. By induction, we 
v' for v' <b Ur. We want to show that 



know that F' f b e 



v' < 0 | <f>' ■ This holds by lemmas [47] and 48 
Case SB_DLet: 

r f™ ei =>■ or r,x:cri lib e2 <= 02 
T Ijb let x = ei in e2 <= 02 



OL_SB_DLet 



Let r' <b T and 02 <b 0 7 be arbitrary. By induction, we 
have r' If™ ei => o[ for o( <b or. By induction (again), 
r', x:o[ f b e2 4= 0'. So we can conclude by SB_DLet. 

Case SB_Skol: 



r, a lib e <= 0 a fL uars(r) 
r f b e <1= Va". 0 



OL_SB_Skol 



Let F' <b T be arbitrary. Result holds by directly by induction 
and SB_Skol. 



□ 



Completeness theorem 

Lemma 54 (Completeness of System SB). 

1 . IfT 1^ e => o the n F If™ e => o' where o' <b <7. 

2. IfT \ i e <= v then T f b e •<= v. 



Proof. Most cases of this lemma either follow by induction, or are 
analogous to the completeness lemma for System V. We discuss the 
most novel cases are B_APP, B_ANNOT, plus the checking rules. 



Case B_Var 



x\a G T 
F f x =£• c 



OL_B_Var 



Let a be V{a}.u. We can use the types a to instantiate the 
variables a. We know these a are not free in T by the Barendregt 
convention. It may be the case that generalization quantifies 
over more variables, i.e. a C o' = ftv(v ) \ uars(r), leading 
to a more general result type. However, that is permitted by the 
statement of the theorem. 

Case B Abs 



T, x'.r 1^ e =4> v 
T f Xx. e => t — > v 



OL_B_Abs 



The induction hypothesis gives us :t lf b ™ e =» V{a}.u' 
where V{a}.u / <b v. Inverting If™ gives us T, x:t 4 e 
v' and inverting <b gives us -t/pf/a] <b u. We can then 
substitute and use SB_Abs to get F A®. e =>■ r — > v'\T/ti\. 
Generalizing, we get T If™ Xx. e => V{a, a'j.r — > t/[r/a] 
where the new variables a' come from generalizing t and the 
t. We are done because (r — > u , )[r/'a] <b r — > v and so 
V{a, a'}. r-H)'<bT-H) 

Case B_App 



r ^ ei = 4 > ui — > V2 T ^ e2 <= vi 
F f ei e2 => V2 



OL_B_APP 



By induction we have F if™ ei => o for some o <b ui — / vi. 
So by inversion a = V{a},6.t>i — » U2, where ( v[ — > 
v ' 2 )[t/< 2 ][t'/&] <b Ur — > V2 and ur <b ui[r/a][r'/6] and 
V 2 [t/o] [t'/ 6] < b U 2 . 



\/b.v[ —t v ' 2 and 



v ' 2 )[t/o] 
=► (vi 



Also by inversion, we know that T f b ei 
that the ~a are not free in T or ei . 

By substitution, we have T f b e\ => V6. (ui - 
And by SB_InstS, we have T f b e i 
v’ 2 )[r/a][r'/b\. 

By induction we have r f b e2 4= vi and by lemma 
know that F f b e2 <= v{[t /<x][t' / 6]. 

So we can conclude F f b ei e2 <= v 2 \f /lf\\f' / b\. 

CaseB Let 



53 



r lb ei => cri T, ®:or f e2 



T L let x = ei in e2 



OL B Let 



The induction hypothesis gives us T f™ ei =>■ o( with of <b 
<7 1 . The induction hypothesis also gives us T, x\ui f™ e2 =4- 
(72 with a 2 <b <j 2 . Use Lemma|53|to get F, x:a{ f ™ e2 => a 2 
where a 2 <b o' 2 . 

Let o 2 = V{6}.u where b = ftv(v ) \ vars(T). Inverting 
f™ gives us F, x:o{ f b e 2 => u. We then use SB_Let 
to get r f b let® = ei in e2 =4> u. Generalizing gives us 



T f™ let x = e\ in e2 => V{6}. v. 

Transitivity of <b (Lemma 24 1 gives us V{6}. v <h rt 
Case B_Int 

OL B Int 



<J 2 - 



Tf n: 



Int 



Trivial. 

Case B_TApp 

r hr 



T L e => Va. v 



OL B TAPP 



■ v[r/ a] 

The induction hypothesis (after inverting f b ™) gives us T f b 
e => Va. v' , where b = ftv (V a. v') \ vars (F) and v'\r/ 6] <b 
v. Applying SB_TAPP gives us T f b e@r => u'[r/a], 
and SB_Gen gives us T f™ e @r =4- Vlcj.ufr/a] 
where c = ftv(v'[r / a]) \ uars(r). We want to show that 
V {c} . v' [ t / a] <b u[r/a], which follows when there is some 
r', such that u'[r/o] [r'/c] <b u[r/o]. 

This is equivalent to exchanging the substiution, i.e. finding a 
t' such that ufr'/cl [r/a] <h ufr/ a]. 



By Substitution (Lemma 22 1, we have v'[T/b][r/a\ <b 



v[t / a] . We also know that the b are a subset of the c. So we 
can choose t' to be r for the b, and the remaining c elsewhere, 
and we are done. 

Case B_Annot 



r i-u 



Tf (e:u) 



OL B Annot 



The induction hypothesis gives us F If e 
immediately follows. 

Case B_Gen 

T f e => a a ^ uars(r) 



u, so the result 



Ff e: 



OL B Gen 



V{a}. a 

The induction hypothesis gives us T f ™ e =t- a' where a' <b 
a. We know <r' <b V{a}. a. In other words, if o' = V{6}. Ui 
and <7 = V{c}. U2, we have some r such that ui \r/b\ = V2- 
By the definition of <b we can use these same r to show that 
o' <b V{a, c}.U2. 

Case B_Sub 

<Tl <b 02 



T f e ■ 



CTl 



OL_B_Sub 



<72 



The induction hypothesis gives us T f b e 
<0 <b <7i. By transitivity of <b , we are done. 



o' where 
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Case B_DAbs 



T, x:vi e <= V2 
T ^ Xx. e <= vi — > V 2 



OL_B_DAbs 



By induction, we have that T, x:vi [f b e -£= V2 ■ Therefore by 
SB_DAbs, we can conclude T [f b Xx. e <= vi — >■ V 2 . 

Case B_DLet 



T ^ ei => cti T, x:ai ^ e 2 4= v 
T ^ let x = ei in e 2 4= v 



OL_B_DLet 



By induction we have T, x:oi [f b e 2 4= v. Also by induction, 
there is some a 1 < b cti, such that T lf b ” e =$■ o' . By context 
generalization, we know that r,x:a[ [f b e 2 4= v. So we can 
use SB_DLet to conclude. 

Case B_Skol 



Y,a\^ e <= v a wrs(T) 
T ^ e <= Va. v 



OL_B_Skol 



By induction, we have T, a lf b e <= v. We can conclude 
using SB_Skol. (Actually, first inverting and then potentially 
applying SB_Skol multiple times). 

Case B_Infer 



Vl 



Vl <ol V2 



Fh b e- 



OL B Infer 



: V2 



By induction, there is some o' < b vi, such that T [f b n e =$■ o'. 
By inversion of lf b " we know that o' is of the form V{ rz} . v' 
and that Y [f b e => v' , where a do not appear in e and T. 

By inversion of < b , we know that -t/pf/a] < b vi. By substi- 
tution, we know that T t | h e => v'\r/^a\. 

By transitivity (Lemma 47 i we know that t/[r/a] < 0 i V2 ■ So 
we can conclude using SB_lNFER. 



□ 



G.6 Comparison with Dunfield / Krishnaswami 

The presence of the non-deep-skolemization System B, makes it 
easy for us to compare our type system with the system designed 
by Dunfield and Krishnaswami. (We refer to this system as DK in 
the following.) In particular, we can show that our system subsumes 
the DK system. 

Suppose T b dk v\ ^ V2 is the subtyping relation from the DK 
paper. Figure 1. 

Lemma 55 (Higher-rank subsumption contains DK subtyping). If 

Y b dk vi ^ V2 then v\ <oi V2. 

Proof But induction on the DK subtyping judgement. 

Case DecLC Var Immediate from DSK_Refl. 

Case HeclbUnit Immediate from DSK_Refl. 

Case Decl<— > Directly via induction and DSK_FUN. 

Case Decl< VL By induction and DSK_Inst. 

Case Decl< VR By induction and DSK_Inst. 

□ 

The DK system includes an application judgement, written 
T b dk v\ o e V2. which means "applying a function of type 
Vi to e synthesizes type tV'. 

Our declarative system does not need this judgement because 
we allow implicit instantiation for specified polytypes. In our sys- 
tem, the rule B_SUB allows instantiation at any point in the judge- 
ment. However, in the DK system, instantiation is restricted to be 
immediately before an application or when synthesis mode and 
checking mode meet (via subtyping). This is what our algorithm 



actually does, but because we have the instantiation relation, our 
declarative system need not make this constraint. 

Lemma 56. If T b dk Vi o e V 2 then there exists some v'i 
such that vi < b v[ — » V 2 and Y b dk e 4= vj. 

Proof. Proof is by induction on the judgement. It requires an ob- 
servation about our instantiation judgement that if vi < b v'i — > V 2 
and vi is V6. p, then we must have instantiated all of the b in the 
judgment. In otherwords, that p[r/b] = v'i — > t> 2 - 

L! 

Now let T b dk e => v, T b dk e 4= v be the judgements 
shown in Figure 4 of their paper. We can also argue that System B 
can typecheck the same terms. 

Lemma 57. 

1. IfY b dk e <= v then Y ^ e <= v. 

2. If Y b dk e =4- v then Y ^ e =£* v. 

Proof. Proof is by induction on derivations. Most cases have direct 
analogues in System B. Note that technically we replace their unit 
type with int. They view the checking rule for the unit value as 
primitive and add a synthesis rule for convenience. Our system does 
not have a checking rule for constants, but can derive one from the 
synthesis rule and B_Sub. 

The only other case that requires additional reasoning is the 
convenience rule for inferring the types of functions. We need to 
use lemma |5T|to convert a checking judgement for monotypes into 
a synthesis judgement. □ 
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